Hotkeynet comming back?

[Freddie]

Thanks a lot for clarifying. I'd like to make sure I understand 100% before I throw out more ideas, so let me give a concrete example, and if it's not exactly the soft of thing you want to do, please correct me.

Example:

With one hand, on the PC, you hold down numpad2 so the command goes to a particular window. While that key's down, with the other hand, on the Nostromo, you press (for example) alt-ctrl-7 which means "fire some particular spell." Then you release all the keys.

If you had held down numpad3 or numpad4 instead of numpad2, the same thing would have happened except the command would have gone to some other window(s).

Is that the idea?

[Basilikos]

That is exactly it. Note also that it would be nice in this setup for NUMPAD0 to be a general broadcast as well as NUMPAD7 and NUMPAD9 sending commands to both clients on either slave machine. Basically, the idea would be granular control of every character.

[Freddie]

I can create this behavior in several different ways. I'm going to think out loud here for a minute in case somebody has a suggestion.

Each way has advantages and disadvantages.

(1) The first way is what you originally suggested, i.e., let the user define numpad2 as a modifier. My initial objection was wrong because keys get disabled every time they get assigned as unmodified hotkeys. This is no worse. The only thing that's different about this is that the result may be unexpected. This can be handled by making the syntax very explicit so the user gets a warning simply by writing the hotkey file. E.g., something like <TreatKeyAsModifier numpad2>.

Advantage over other methods: easy for me to implement.
Disadvantage: you (Basilikos) will have to define a huge number of hotkeys -- one for every possible combination of numpad keys and Nostromo keys.

(2) Transient state variables. Don't get alarmed, these state variables only exist while you hold down the numpad key. When you release the key, they destroy themselves. So there's no permanent state. This idea requrires either (a) implicit exposure of the variables to the user in the hotkey file or (b) explicit exposure or (c) if-conditions in the hotkey file.

(2a) Implicit variables. For example, the user defines <hotkey numpad2> with new command <SetDefaultDestination 192.168.1.101 WOW1>. Also defines <hotkeyUP numpad 2> with new command <ClearDefaultDestination>. This <HotkeyUP> definition handles your objection about permanent state. Then the user defines Nostromo hotkeys without SendPC and without SendWin.

advantage: it would be pretty easy to design < SetDefaultDestination> so it takes not just one destination as its argument but a list. Then the Nostromo hotkey could broadcast the command to the whole list. There's your broadcast.

disadvantage: without the list, same disadvantage as (1).

(2b) Explicit variables. For example user defines <Hotkey numpad2> with <DefineVariable $TargetWindow = WoW1>. Defines <hotkeyUP numpad2> with <ReleaseVariable $TargetWindow>. (That answers your objection about permanent state.) Defines Nostromo hotkey with <SendWin $TargetWindow>

disadvantage: Very geeky. This is over the heads of most users.
advantage: same as (2a) but probably more powerful as a long term part of the program that will get used elsewhere.

(2c) If-conditions. The user wouldn't define anything for numpad2. Just a hotkey for each Nostromo definition. Something like:

<hotkey Alt Ctrl 7>
<if numpad2 is pressed>
<SendPC 192.168.1.101>
<else>
<SendPC 192.168.1.102>
etc.

disadvantage: might be a lot of work for me to implement. I don't feel like writing a real interpreter for this program. Probably less work for the user than (1) but more work than (2a) or (2c) assuming I implement the lists.

advantage: it's geeky but probably easier for people to use than the explicit variables.

[Basilikos]

I still like the first option. I think it leaves the most open to the users. And as for me making a TON of hotkeys, that's not an issue (but it probably is for others). I have a script that generates the hotkey file for me.

Also, I wouldn't expect the other options to be viable since they involve the whole variable thing or a bit of programming for other users (and writing an interpreter is not something I'd ask you to do). I could handle the programming of the hotkey definitions easily, but that's just not a feature fit for your general audience, imo.

Anyhow, thanks again.

[Freddie]

Welcome.

I just checked to see how AutoHotkey handles "any key can be a modifier." In that program, users can define any key as a modifer but only in two-key combinations. So you could define <numpad2 A> as a hotkey but not <shift numpad2 A>.

I don't know why he made that restriction. If I implement this, i'll try to make the maximum number of keys as large as possible.

He does a subtle little thing about the disabling of the new modifier. If you have a hotkey defined for the modifier by itself, that hotkey will now fire when you release the modifier instead of when you press it, but only if another hotkey didn't get triggered while the modifier was down. AHK is filled with little details like that; it's the personality of that program. I don't especially like it when a program changes its behavior in complicated ways in an effort to help me; I find it confusing and I would prefer the program to simply be consistent. But some people like it a lot; it's a matter of taste.

[Draku]

For what it's worth......I'll add my vote.

I also think option 1 is best,. It is easy to understand and sounds like it is easiest to implement.

Although, having said this, I am not sure I will use this, My multi-boxing style is to use my KM (ie keyboard/mouse across my pcs) to make tweaks on a character by character basis. I keep the HKN stuff to handle group actions

[Freddie]

Explicit variables would be easiest. Custom modifiers would be harder. And before I can add them, I need to think of a simple algorithm for matching the keyboard state against the list of hotkey triggers. I haven't thought of a good one yet. Maybe somebody has a suggestion.

The difference isn't just time spent writing. New code for variables can be dropped into the program, and if it works at all, will probably be bug free. But modifiers require rewriting the core logic of the keyboard hook with a lot of fiddling and testing.

[Basilikos]

Well, do whatever is best for you since in this case, they all accomplish the same thing. My only concern was that some users who might not be as technically inclined as others may not be able to use the variable features. Although, since definitely in the user group that would have an easy time with any of these options, my judgments may not be so accurate.

[Freddie]

I thought up a decent way to do it but the number of "extra" modifiers will be limited to a maximum of 16 or maybe 20. That's the max number of keys that can be "disabled" to be used as modifiers. Do you think that's good enough?

(It's also the max number of custom modifiers you could use in the trigger of a single hotkey -- i.e. you could define a hotkey that's triggered by 16 or 20 custom modifiers plus 3 regular modifiers plus a main key -- but I don't think that limit is a problem.)

[Basilikos]

I thought up a decent way to do it but the number of "extra" modifiers will be limited to a maximum of 16 or maybe 20. That's the max number of keys that can be "disabled" to be used as modifiers. Do you think that's good enough?

(It's also the max number of custom modifiers you could use in the trigger of a single hotkey -- i.e. you could define a hotkey that's triggered by 16 or 20 custom modifiers plus 3 regular modifiers plus a main key -- but I don't think that limit is a problem.)

That is absolutely enough. I don't see any problems with that at all.