Target/Mapped Key Step resolution

[Alge]

I'm trying to debug a fairly complicated mixed class config that heavily uses Virtual Mapped Keys to manage multiple ability rotations (which I want to be able to switch between) per character. I'm not quite at the point where I'm ready to just link to my config and see if someone else can figure out the problem. Anyway, to assist my endeavours I'd like to know the following:

1. When I assign a Target for an Action in a Mapped Key, what does the target get resolved to? I mean, does it end up getting interpreted as a window or a character or a character slot or something else?
2. When a Mapped Key gets virtualised to other Mapped Keys (on a per character basis), each of which potentially has multiple and different steps, on what basis (global, character, character slot, window or something else) is the current step of each of those Mapped Keys saved?

Thanks,

Alge

I'm trying to do the same sort of thing, to switch between (for example) shot rotations for heroism and no-heroism. The additional haste speeds up the rotation, but with my hard-coded times between steps prevents any DPS gains. I'm thinking I'll virtualize the DPS rotation and use the heroism key to switch disable the normal rotation and enable the heroic rotation (with faster timing).

1. Ultimately, the target resolves to a slot. As I understand it, each slot is running a copy of the keymapper. Each keypress goes to 'self' which then interprets it according to the keymap. If a step refers to something other than 'self', the action is sent to the keymapper running on whichever slot(s) are required, which can then forward the action on to additional slots.

2. The keymapper on each slot should keep track of the step for that key. So, if you send 'x' to slot 1 it will advance to step 2. If you send 'x' to slot 2 twice, it will advance to step 3 and slot 1 will still be on step 2. It gets tricky when you are using 'self' since 'self' can refer to either slot, depending on which screen is active. I think of virtualization as hiding a mapped key. I believe the original key is still on the step it was on before being virtualized.

Note, you can turn on the debug console from the innerspace gui, enable virtualization and watch how each slot processes the keypresses.

Note, also if you have an key with no actions at all things don't seem to work right. I make all the 'dummy' keys:
step 1: set keymap/key to step 1
so none are empty. Otherwise I think the key gets optimized away and even virtualization doesn't work right.

[Alge]

Thanks for the response. That is how I thought it would work. It has given me some more ideas of things I need to check. I do have some mapped keys with no actions which should only ever be virtualised. Your response has helped trigger a memory of Lax (if I am remembering accurately) suggesting giving such Mapped Keys a Popup Text Action so you could tell if they weren't being virtualised properly, i.e. you should never see that text.

Back to it I go

EDIT: Thanks for pointing me back at the debugger. I hadn't realised it allowed you to track Virtual Mapped Keys. And while I'm here... Lax, you rock for adding the debugger! I've already found a whole bunch of errors.

EDIT 2: Got it all working how I want it for now. Thanks again.