Build 16: Alt-tab bug fixed

[Freddie]

thx.

I spend a good hour or two last night trying to break it (lots of alt-tabbing and other weirdness) - no issues.

Great.

So what's next?

Like Zenga says, let's get rich!

Let me try to remember recent requests.

The next thing on your list was keymaps. I think the next thing on Moorea's list was no-pass. That's sort of the same, right?

I might have to do "launch WoW" before keymaps make much sense.

Other people asked for visible cursors, status overlays, um, what else.

Edit: mouse broadcast.

Edit: Set a PC not to receive incoming (as opposed to the existing mode buttons and hotkeys which all affect outgoing).

Edit: re-enable WoW window and finish the code that tracks scheduled and running WoWs.

Edit: Triggers need to be finished. They don't yet include an option for "trigger when key is released" and "allow or disallow typematic presses to trigger this hotkey."

Edit: There are two remaining bugs on the bug list but I'm inclined to leave them for now since they will be a pain in the ass and nobody has complained about them.

Moorea, if you're reading this, you know what would help me in the FAQ? If you could figure out some way to include a running summary of requests with a count of how many people asked for each one. A top-ten requests list. Right near the beginning of the FAQ.

Does the word "keymap" come from Keyclone? Can someone post a screenshot of what a keymap config screen looks like so I have a better idea of what's being requested?

[zenga]

The next thing on your list was keymaps. I think the next thing on Moorea's list was no-pass. That's sort of the same, right?

How i see it is that keymaps and don't pass are essential functionalities for a boxer and it would take mojo to the next level.


Keymaps: e.g. map ctrl+A to jump on toon A and B and move forward on C while both ABC have exactly the same ingame keybinds

Do not pass: respective keypresses are not passed to all clients, only to the active window. If we could decide to which clients it should be passed and to which not, would even be more awesome. For example i have my arrow keys set as main movement keys on all clients and i have ZQSD as my secondary movement keys on my slaves (not on my main). The arrow keys are not passed to slaves. This means i can just move around with my main with the arrow keys and have my slaves on follow. If i need to move my slaves out of a puddle in a bossfight, i just use ZQSD. On the other hand if i switch to a slave i can just use the arrow keys to move around like i'm used to without my alts responding.

[Freddie]

Keymaps: e.g. map ctrl+A to jump on toon A and B and move forward on C while both ABC have exactly the same ingame keybinds

Could you please clarify that for me? For any trigger, there are three things involved:

-- the key or key combo that's pressed by fingers physically

-- the key or key combo that Mojo sends to WoW

-- the in-game action .

Could you restate that example in terms of those three things?

Do not pass: respective keypresses are not passed to all clients, only to the active window. If we could decide to which clients it should be passed and to which not, would even be more awesome. For example i have my arrow keys set as main movement keys on all clients and i have ZQSD as my secondary movement keys on my slaves (not on my main). The arrow keys are not passed to slaves. This means i can just move around with my main with the arrow keys and have my slaves on follow. If i need to move my slaves out of a puddle in a bossfight, i just use ZQSD. On the other hand if i switch to a slave i can just use the arrow keys to move around like i'm used to without my alts responding.

That will definitely be in the program. That's why I said above that I might have to do "launch WoW" before no-pass. The program will need to launch WoW in order to provde the user with config screens that refer to individual WoWs.

[Freddie]

Be sure to include "ActiveWindow" and "!ActiveWindow" in your options - Sometimes I mouse over to a slave machine and start playing from there, and I would love it if it just mapped my keys accordingly.

Definitely, the program should provide these options.

The problem is designing an interface that makes it easy to choose. Do you have any ideas about that?

PiP, and PiP "Positional Awareness/Preference" - the second part is a little difficult to explain but let me try:
In Octopus I have 2 screens setup - 4 WoWs in a 2x2 config and 1 WoW that takes the whole screen. If I have the WoWs configured as:
A is Main Screen
B is Top Left Secondary Screen
C is Top Right Secondary Screen
D is Bottom Left Secondary Screen
E is Bottom Right Secondary Screen
[B|C][AA]
[D|E][AA]

If I press the PIP button associated with B, it will swap A with B:
[A|C][BB]
[D|E][BB]
If I then press the PIP button associated with C, it will swap B with C:
[A|B][CC]
[D|E][CC]

The problem with this, is that I want B to either be Main or Top Left, I never want it to be Top Right (which is where it is now). I can get around this by ALWAYS pressing the PiP associated with A first and then the PiP assocciated with the WoW of my choice ... but I would rather it take care of that in the background so I can hit it quickly when I need to.
Since some people may not want this (because it means moving 2 screens sometimes, which may take longer) it would need to be an option that could be set either way.

Let me know if this is clear.

Yeah, it's crystal clear. People should be able to define keys that change their PIP setup in any way they want. That includes such things as defining which WoW's window goes where, which window-by-current-location goes where, conditions such as which WoW is currently in the foreground, etc. (And do this without using the script language. Of course users will be able to do anything whatsoever with the script language).

Do you have any ideas for how to design the interface where people create their PIP layouts and their PIP hotkeys?

I'd like to give people completely generalized choices, so there are a lot of permutations, but I'd also like the screen(s) to be extremely easy to use.

[Freddie]

What I try to do is push everything I know technically out of my head -- forget everything I know about the code -- and imagine using the program. Then I ask, "What would be the easiest thing to see on the screen and move with the mouse?"

The bad thing is, usually there's no answer.

The good thing is, my advancing Alzheimers makes it easy to forget what I know. I'm great at that part!

[Freddie]

EDIT:

I think Innerspace uses ActionTargetGroups (don't know, never used it) and Keyclone uses Keymaps. The thought I had was this:
A small screenlet (tab/popup/doesn't matter) to define "KeyTokens" or "Keymaps" or whatever you want to call them. The idea is that the client that has focus will call this "token" when a key is pressed or a mouse-region is clicked. On this screen you click an Add button and you get a name screen and an "input" box, which has a checkmark for "Keyboard-In" and "Mouse Region-In" with Key In pre-selected and "Mouse Region-In" unselected. Under "Keyboard-In" is a key-input box. Under "Mouse Region-In" is a 4xBox for X,Y,Height,Width along with a "click-trigger" (left mouse, ctr-left mouse, etc). Finally, there is a button at the bottom that says "view mappings" - this pulls any "client" that currently has this "Token" mapped. This is just a convenience click-through.

http://s333.photobucket.com/albums/m...pExample01.jpg

Thanks for the screenshot and for pointing out the edit in a later post. I would have missed it otherwise.

I'm confused here about a basic point. There are three "things" involved in key injection.

1. The key combination (button, whatever) that the user presses with his fingers.

2. The key combo that Mojo sends to WoW. This appears in WoW on the right side of its key bind screen.

3. The action that number 2 is bound to in WoW. This appears in WoW on the left side of its key bind screen.

Are you suggesting that 2 should be hidden from the user and that Mojo should set keybinds in WoW without the user worrying about it (in other words, Mojo should change the in-game key bind screen)?

[Freddie]

I don't think you answered my question. I apologize if I'm missing it.

Let me try again.

You say, Q - Move Left.

That's a binding in WoW.

What our program is actually going to do is send Q to WoW.

But your window doesn't say "Send Q." Your window says "Move Left."

Q is bound to Move Left in Wow, not in our program.

How does our program know that Q is bound to Move Left in WoW?

(The number of instances, the fact that the choice of Q instead of some other output is conditional, etc. etc, is not the issue. The issue is how our program knows or sets any WoW binding whatosever. I'm using Q-MoveLeft as an example of a binding.)

[Fursphere]

Great.


Like Zenga says, let's get rich!

Deal!

Let me try to remember recent requests.

The next thing on your list was keymaps. I think the next thing on Moorea's list was no-pass. That's sort of the same, right?

I might have to do "launch WoW" before keymaps make much sense.

Actually yes, the "Launch WoW' feature would be really really cool.

Do not pass lista and keymaps are similar - but still different.

Do not pass has been described as a "white" and "black" list as well. THe most often used feature of this is for movement keys. WASD. So on the "boardcasting" mojo (current focus or main) - all keys would be broadcast (white list keys) EXCEPT "WASD" (blacklist). Its basically a list of keys you would tells mojo to "not boardcast".

The benefit here is you don't have to redo keybindings within WoW. And if you make a new WoW your "focus" or "main" - your movement keys are already setup - no rebinding. A seamless transfer.

Keymaps are changing the logical mapping of keys from one mojo to the next (or wow to wow on same pc setups).

Example:

WoW1 = A is pressed
WoW2 = A is mapped to B
WoW3 = A is mapped to C
WoW4 = A is mapped to D

So when you press A on the main, B, C, or D gets pressed on "alt" WoW's depending on there individual keymappings. I personally don't like this concept - but a lot of others have come to love it with the other broadcasting soloutions.

Other people asked for visible cursors, status overlays, um, what else.

Edit: mouse broadcast.

I don't think you've even written the code for mouse broadcasting yet? I'm not sure how many people actually use this on a day ot day basis vs. a "neat toy to have" feature. Would be interesting to find out.

Edit: Set a PC not to receive incoming (as opposed to the existing mode buttons and hotkeys which all affect outgoing).

Edit: re-enable WoW window and finish the code that tracks scheduled and running WoWs.

This is going to be very handy for multi-client users (more than one WoW per PC). It looks like you're half way there with the new "WoWs" button info.

Edit: Triggers need to be finished. They don't yet include an option for "trigger when key is released" and "allow or disallow typematic presses to trigger this hotkey."

You can currently do creative binding IN GAME to do "on release" stuff. How many people actually use it? Not many I would suspect. I really don't know a practical use for binding "on press" vs "on release"

Edit: There are two remaining bugs on the bug list but I'm inclined to leave them for now since they will be a pain in the ass and nobody has complained about them.

Oh? I haven't notice them yet. What are they?

Moorea, if you're reading this, you know what would help me in the FAQ? If you could figure out some way to include a running summary of requests with a count of how many people asked for each one. A top-ten requests list. Right near the beginning of the FAQ.

I was considering doing this myself. Let me talk to Svper and see if I can get some mod access to clean things up a little on this forum.

Does the word "keymap" come from Keyclone? Can someone post a screenshot of what a keymap config screen looks like so I have a better idea of what's being requested?

I dont' know where the term came from. As far as a UI goes... hmm.... with the amount of keys available on a keyboard, the UI could get HUGE. I'm almost thinking some sort of spreadsheet type layout with a list of "input key" in one column, then multiple "output" columns on a per WoW basis (multi PC aware). So you can just type in what key you want output based on the input key.

Maybe even a dynamic hotkey system like you do in the other menus - that add boxes as you use them?

[Freddie]

Example:

WoW1 = A is pressed
WoW2 = A is mapped to B
WoW3 = A is mapped to C
WoW4 = A is mapped to D

So when you press A on the main, B, C, or D gets pressed on "alt" WoW's depending on there individual keymappings. I personally don't like this concept - but a lot of others have come to love it with the other broadcasting soloutions.

I think the program should do that. I think also that this sort of setting should nest. I.e., a single setting of this type for all WoWs. Then individual settings for individual WoWs that might override only a few keys. (I think all config info in the program should work that way.)

I don't think you've even written the code for mouse broadcasting yet? I'm not sure how many people actually use this on a day ot day basis vs. a "neat toy to have" feature. Would be interesting to find out.

I haven't written it yet but I've written this kind of code before in HotkeyNet.

This is going to be very handy for multi-client users (more than one WoW per PC). It looks like you're half way there with the new "WoWs" button info.

Unfortunately I just decided to rewrite the code that underlies that button. The xml file for config info, the data structures that represent WoWs and all other config'd objects -- out it goes. I've been having a lot of trouble getting it designed in a way that will make the rest of the program easy to write (it has to support the nesting stuff above and some other operations).

(Continued in another post)

[Freddie]

You can currently do creative binding IN GAME to do "on release" stuff. How many people actually use it? Not many I would suspect. I really don't know a practical use for binding "on press" vs "on release"

It's necessary for some very simple things in the script language. For example, making a hotkey that causes movement in a game. I won't work on the script language for a while, but the trigger code I wrote last week is the same code that will be used for the script language.

Oh? I haven't notice them yet. What are they?

Actually there are three known bugs now. Somebody told me one last night in a game.

1. When you close a Mojo, a connected Mojo may not close both its socket connections. Then when you reopen the closed one, the connection may not get fully reestablished.

2. If you close a Mojo whlie moused over, one or both cursors may get disabled or trapped.

3. Last night somebody reported that remote mouseover cursor gets trapped in a window belonging to Dark Age of Camelot.

I was considering doing this myself. Let me talk to Svper and see if I can get some mod access to clean things up a little on this forum.

Omg you're going to mod again!

I dont' know where the term came from. As far as a UI goes... hmm.... with the amount of keys available on a keyboard, the UI could get HUGE. I'm almost thinking some sort of spreadsheet type layout with a list of "input key" in one column, then multiple "output" columns on a per WoW basis (multi PC aware). So you can just type in what key you want output based on the input key.

That's kinda what I was thinking too. Except with the nesting idea maybe the entries should be color coded to show whether they are inherited (defined in a parent setting) or overriden in the current setting. And maybe there should be tabs to look back at parents from which the current settings are inherited.

And then I think -- this is too complicated for Mojo.

I never counted but the OS probably defines something like 150 or 200 key codes.. In addition some hardware devices (by mistake) use non-existent key codes so in a way there are 512 because the codes are defined by nine bits.

Maybe even a dynamic hotkey system like you do in the other menus - that add boxes as you use them?

We can draw the boundary between "broadcast" and "hotkeys" anywhere we like.

Broadcast is just a subset of hotkeys, and it can include as much hotkey stuff as we want.

I'm thinking that the input to broadcast (the trigger) should always be a single key press or release. Whether the output can be a combination... I dunno, that's something to decide.

Certainly, the program will be able to do that, but I dunno which part of the program should do that ... which screen the user does it on, whether it's called broadcast or something else.