What should this do?

[Iru]

The following is a snippet of valid pwnboxer keymapping configuration

{
	"Active Window" : 0,
	"Input Key" : "Alt + Up",
	"Output Key" : "None",
	"Output Window" : 0
},

{
	"Active Window" : 0,
	"Input Key" : "1",
	"Output Key" : "Num1",
	"Output Window" : 0
}

The way the first re-mapping code appears in the user interface suggests that using it will simply prevent the key sequence from being passed to Game 1; a possibly desirable situation as by default that key sequence would move the main toon (think using Alt+arrow keys to move slaves only). It also suggests that the second remapping sequence will act as a meta-rebinding function; less useful perhaps but possibly valuable if the the main toon is also used for solo play and the player doesn't want to deal with rebinding attack keys between /click macros and direct casts (think pally tank). This is not the case, however, and instead the re-mapping sequences have no effect at all, and the original key presses are just passed through to game 1.

In the interests of complying with the Law of Least Surprise, I'd like to suggest that pwnboxer do one of two things:

1. Have the UI refuse to allow such configurations. Basically, don't allow the user to select a target game that matches the source game, which would at least ensure the UI was accurately representing current behaviour.
2. Block the initial key sequence from passing through, and substitute the replacement key sequence instead, or simply block the key sequence if 'None' is selected.

While the first is probably easier, the second would provide a much more powerful set of capabilities to the user, and is certainly my preference.

Thoughts?

[TheMuffinMan]

I ran into this identical situation last night.

[Iru]

WTB blue post

[fogy]

Bump. Relates to my question Feature request: User-independent mapping

[Tim]

I'm not 100% sure about your question, but the remapping is for key broadcasting, which means you can only remap keys to windows you are broadcasting to.

[Iru]

But it's a small abstraction to see pwnbxer "broadcasting" to all the games, not just the slaves, which leaves my original question unanswered.

Pwnboxer is already sitting between me and WoW. I just want to sit between me and all the clients equally.

[Tim]

Okay so you lost me here heh, what is your original question? You want to make a key remapping have an option to send no key to a slave window VS sending a key?

[Iru]

No, that already works.

I want the keymapping rules to apply to all windows equally, not treat the main window as a special case. That way if I want to map '1' to '2' or map '1' to 'do nothing' on my main window I can.

[Tim]

It isn't so much treating the main window specially, it is more about how windows works. Pwnboxer broadcasts the keystrokes to other windows, which means it doesn't change what you do to your currently selected main window.

While that would be possible, that would require the program to do things Blizzard doesn't want done to the wow.exe program. Pwnboxer is built using very safe programmatic methods, so doing things that Blizzard has stated is a no no, is, well, a nono

[Iru]

That argument is spurious in the case we're discussing, Tim. If it is acceptable under the ToS to transform a single key event into a different single key event before sending it to a secondary window, it is equally acceptable to do it before sending it to the main window.

You're already doing things to WoW.exe to make that happen. I'm just asking for you to do them consistently.