[HotKeyNet] Sending keystrokes from slave to master?

[Freddie]

I can't believe that after looking through pages and pages of Google results for HotKeyNet, FTL, etc. that I never once seen anything stating to put a script on the slave client. It might have been stated and I just missed it...

I'm sorry. I'm not sure what I can do to make it more clear. HotkeyNet's website says repeatedly that every instance of HotkeyNet has the same abilities. For example, the home page says that you can press a hotkey on any keyboard.

For years, I used to add a sentence like, "With HotkeyNet, every copy can do the same things," to nearly every forum post. I must have done this several hundred times.

The program doesn't distinguish instances of itself. They are all the same. You can load scripts on as many instances as you want.

The problem here is that users assume something that isn't true. I never told them this false thing. They simply assume it on their own. They assume that the server copy of HotkeyNet is a master and the client copies are slaves.

This assumption has always seemed bizarre to me because by definition, a client is a thing that sends commands and a server is a thing that carries out commands. Everybody knows this (or should know this) from web browsers, which are the most common examples of a client-server program. When you tell your browser which web page you want to see, it sends a command to the server. The server, not the client, is the slave.

In fact, "server" is almost a literal synonym for "slave." A slave is a person who is bound to service. "Client" is almost a synonym for "patron", i.e., master. But for some reason people imagine that "server" means "instance that sends commands." I really don't understand it.

But all of this is irrelevant in HotkeyNet's case. With HotkeyNet the client-server distinction only applies to the communications protocol. It has no effect on anything that the user can see. It has no effect on scripts or hotkeys.

I guess part of the problem is that WoW boxers usually think of their groups as consisting of a master and slaves, and they assume HotkeyNet must share this idea. But HotkeyNet has nothing in particular to do with WoW. It's a general purpose hotkey program.

This misunderstanding is one of HotkeyNet's worst problems because it makes people think the program is much less powerful than it really is. If they run four instances of HotkeyNet, they are ignoring three quarters of the program's potential power.

The way I've solved this problem with Mojo is to eliminate clients and servers. Mojo is peer-to-peer and every copy is identical in every way. People won't be able to assume that one instance is different from the others because the instances are indistinguishable.

Here's the revised example script and the slave client script I used to test (just in case this helps someone else):

Nice job!

It looks like you're pressing NumPad1 on both keyboards with your finger. If you want to reach back and forth like that, it's perfectly fine.

I myself use three keyboards when I multibox -- I'm really not criticizing this. I like using three keyboards.

But just so people know, if you want, you can set this up so you only have to press one keyboard. You would use <DoHotkey> on your main keyboard to trigger hotkeys on the other computers.

Thanks again for your help! I was getting fed up with searching, which is why I made a thread. It takes a lot of agony to get me to ask for help. I'm a big believer in Google, hehe. Now I can get back to the fun stuff.

You're welcome! Thanks for posting.

[Nomahd]

I'm sorry. I'm not sure what I can do to make it more clear. HotkeyNet's website says repeatedly that every instance of HotkeyNet has the same abilities. For example, the home page says that you can press a hotkey on any keyboard.

For years, I used to add a sentence like, "With HotkeyNet, every copy can do the same things," to nearly every forum post. I must have done this several hundred times.

That figures... I hate it when that happens. I looked everywhere but right in front of my eyes. But you are right, I assumed HotKeyNet was like a "Master and Slave" type of program.

It looks like you're pressing NumPad1 on both keyboards with your finger. If you want to reach back and forth like that, it's perfectly fine.

I myself use three keyboards when I multibox -- I'm really not criticizing this. I like using three keyboards.

But just so people know, if you want, you can set this up so you only have to press one keyboard. You would use <DoHotkey> on your main keyboard to trigger hotkeys on the other computers.

No, I only use one keyboard. Input Director allows me to use one keyboard/mouse to control multiple computers. So when I move my mouse cursor to another monitor controlled by a different computer (like a multi-monitor pc), the mouse and keyboard output is transferred over to the computer controlling that monitor. So when I pressed Numpad1 on the keyboard it gets sent to whatever PC currently has the focus of the keyboard.

Speaking of Input Director, it IS a master/slave type of program. Which is another reason I was tending to think of HotKeyNet as the same. It also allows macros activated by hotkeys, but not with conditions and no way to toggle hotkeys on or off as far as I could tell. Which makes that function useless to me. But the ability to clone the mouse movement/clicks across multiple computers is handy at times.

I know HotKeyNet allows mouse clicks to be sent to multiple windows, and I use it for that. But it's not the same as a true clone of the mouse cursor. What I mean is live broadcasting of the mouse movements. If I move the mouse cursor in a circular pattern around the screen, the mouse cursor on the other computer does exactly the same in "real time".

I was looking at your Mojo the other day. It looks promising and I can't wait until it's done so I can give it a go! If you can implement the broadcasting abilities of Input Director into Mojo, and Mojo can do anything HotKeyNet can do, I wouldn't need anything else to multibox.

[Freddie]

I was looking at your Mojo the other day. It looks promising and I can't wait until it's done so I can give it a go! If you can implement the broadcasting abilities of Input Director into Mojo, and Mojo can do anything HotKeyNet can do, I wouldn't need anything else to multibox.

Old Mojo (which can still be installed from mojoware.org) is a full blown KM program. But new Mojo doesn't have any KM stuff in it yet.

Mojo's KM stuff is not master and slave. Every mouse on every computer is equal. Every mouse can slide to other computers and control them.

The thing that makes Old Mojo special as a KM program is that it installs and configures itself automatically. It's easier to set up than any other KM program I've seen. What a difference from HotkeyNet! On the other hand I never got around to putting lock-to-screen in it.

[Nomahd]

The thing that makes Old Mojo special as a KM program is that it installs and configures itself automatically. It's easier to set up than any other KM program I've seen. What a difference from HotkeyNet! On the other hand I never got around to putting lock-to-screen in it.

But does it have as much functionality as HotkeyNet? I stumbled across a post from you about Mojo while looking for an answer to my problem and you said something like HotkeyNet was still your best program to use but that your newest Mojo was going to be better than HotkeyNet when it was finished.

Ease of setup is great. But I would prefer to have a program that can accomplish exactly what I want it to do even if it means I have to spend days/weeks setting it up. That's also why I like Grid for healing in WoW.

I don't find HotkeyNet hard to use at all. But I am also well versed in several different programming/scripting languages as well as experience with reverse engineering (I used to write proggies for games). So I don't know how hard HotkeyNet is to use for the average multiboxer. I'm new to multiboxing and KM software, but old to computers in general.

[Freddie]

But does it have as much functionality as HotkeyNet?

Old Mojo and HotkeyNet are different kinds of programs. They are different categories of software.

Old Mojo is a KM program, not a hotkey program. In other words, Old Mojo is a replacement for Input Director. It's not a replacement for HotkeyNet.

...but that your newest Mojo was going to be better than HotkeyNet when it was finished.

The plan for New Mojo is to combine the features from various multiboxing programs I've written over the years. If I ever finish this project, the result will be much better than HotkeyNet. Mojo will have:

-- automatic installation and network configuration
-- KM features from ProgramW and Old Mojo
-- the new bitcode programming language from HotkeyNet 2
-- the hotkey GUI from Old Mojo

I don't find HotkeyNet hard to use at all.

I wish I could agree with you.

I think HotkeyNet is extremely hard to use, and its script language is very poorly designed. I wrote HotkeyNet originally as a quick and dirty prototype and kept building on a weak foundation.

Four times I started to rewrite it from scratch (ProgramW, HotkeyNet 2, Old Mojo, New Mojo) but each time, for various reasons, I stopped and started over.

New Mojo, if it ever gets finished, will have a real programming language (a virtual-machine bitcode language) which I've already written (the new language is in HotkeyNet 2). The new language is elegant and powerful and much easier to use. All its keywords and constructs are fully generalizable. It has real arguments and data types and return values and variables and functions.

It will also have a GUI for such things as toon/team management, screen layout, hotkey definitions, etc.

It will install itself and configure itself automatically to talk to itself on the user's network (it already has this feature). People won't have to be aware of IP addresses or anything concerning communications.

[Nomahd]

Old Mojo and HotkeyNet are different kinds of programs. They are different categories of software.

Old Mojo is a KM program, not a hotkey program. In other words, Old Mojo is a replacement for Input Director. It's not a replacement for HotkeyNet.

Okay, I see. I didn't read up on the old Mojo much. The impression that I got was HotkeyNet is the way to go until the new Mojo is finished so that is where I stopped. I'll just stick with Input Director for now. It does everything I need that I can't get from HotkeyNet. So there's not much point in switching.

I don't even use Jamba... I don't need it. The in-game macro system can accomplish most of what Jamba can. The things which can't be accomplished through a macro can be scripted in a .lua file. As I said, I like total control.

I think HotkeyNet is extremely hard to use, and its script language is very poorly designed. I wrote HotkeyNet originally as a quick and dirty prototype and kept building on a weak foundation.

Don't sell yourself short. It works very well for what it is. I do find it humorous that the creator finds his own creation difficult to use though.

Every programming and scripting language started on a basic foundation. Then as needs arised and new ideas developed more functionality was implemented into them. Sometimes they were elevated to an entirely new language. Take a look at DOS. It's very old and basic. But it is still in use today.

Writing a HotkeyNet script is the same concept. You start with something basic (I hope). Then as you get new ideas you add more to it and sometimes remove from it.

Everything was working just fine for me as it was. But I wanted more control and FTL was the route I chose to take. That meant completely re-writing my scripts. Now everything is working well again and I'll continue to add more as needs/wants/ideas arise. I did find a problem in the FTL template provided by Olipcs. (See below)

New Mojo, if it ever gets finished, will have a real programming language (a virtual-machine bitcode language) which I've already written (the new language is in HotkeyNet 2). The new language is elegant and powerful and much easier to use. All its keywords and constructs are fully generalizable. It has real arguments and data types and return values and variables and functions.

It will also have a GUI for such things as toon/team management, screen layout, hotkey definitions, etc.

It will install itself and configure itself automatically to talk to itself on the user's network (it already has this feature). People won't have to be aware of IP addresses or anything concerning communications.

That's what I'm waiting to try out.


I don't know if I got a bad example script or if something has changed in HotkeyNet since this was written, but the <PassThrough> in the SendMasterAndSlave template throws the following error:

"PassThrough can only be used as the first keyword in a definition."

//Added FTL Templates
// %1% : Master Key
// %2% : Slave Key
// %3% : Modifier
// %4% : SlavesToSend
<Template SendMasterAndSlave>

        <PassThrough>    <------- This causes the error

        <Sendlabel %4%>
                 <Key %3% %2%>
<EndTemplate>

// %1% : master key
// %2% : slave key
// %3% : modifier
// %4% : Active window
// %5% : Slave Windows
<Template SendLeaderless>
       <If ActiveWinIs %4%>
           <ApplyTemplate SendMasterAndSlave "%1%" "%2%" "%3%" "%5%">
<EndTemplate>

// %1% : master-key
// %2% : slave-key
<Template FTL>
         <Hotkey %1%>  

         <PassThrough>    <------- So I moved it here and everything worked perfect.

                  <ApplyTemplate SendLeaderless "%Trigger%" "%2%" "rctrl rshift" WoW1 "w2,w3,w4,w5">
                  <ApplyTemplate SendLeaderless "%Trigger%" "%2%" "rctrl ralt" WoW2 "w1,w3,w4,w5">
                  <ApplyTemplate SendLeaderless "%Trigger%" "%2%" "ralt rshift" WoW3 "w1,w2,w4,w5">
                  <ApplyTemplate SendLeaderless "%Trigger%" "%2%" "rctrl ralt rshift" WoW4 "w1,w2,w3,w5">
                  <ApplyTemplate SendLeaderless "%Trigger%" "%2%" "rctrl" WoW5 "w1,w2,w3,w4">         
<EndTemplate>

It's a minor issue, but I thought it was worth mentioning. I've completely revamped these templates now anyway. I test for conditions based on what windows exist since I use the same script to launch multiple toon configurations depending on what I plan to do in the game (Each toon has a dedicated window name).

[Freddie]

Don't sell yourself short. It works very well for what it is.

Thanks. I appreciate that. It's not the worst program I ever wrote, but it's much less good than its replacement will be if I ever finish it.

Every programming and scripting language started on a basic foundation... Sometimes they were elevated to an entirely new language. .

That's what I decided to do with HotkeyNet. I designed an entirely new language (implemented in HotkeyNet 2) to replace the old one.

http://www.hotkeynet.com/hkn2/ref/LanguageOverview.html

http://www.hotkeynet.com/hkn2/ref/Functions.html

http://www.hotkeynet.com/hkn2/ref/Types.html

Let me give you an example of the bad decisions I made when I designed HotkeyNet's language. The worst one was not having any end-of-block markers. It makes the language terribly confusing. The language *does* have blocks, and they *do* nest, but since there are no end-markers, the language imposes the block structure according to precedence rules which are described under "Blocks and nesting" in the instruction section of the website. I thought this would be simpler than requiring the user to mark blocks, but in fact it makes things harder because the user has to understand the precedence rules.

I did this as an experiment because I had never seen a language with this kind of design, and I was curious to see how it would work. Well, it works very badly! Now I know why nobody designs languages this way!

I don't know if I got a bad example script or if something has changed in HotkeyNet since this was written, but the <PassThrough> in the SendMasterAndSlave template throws the following error:

This is a good example of how a language's syntax can create confusion

I'll explain the whole thing from the language designer's perspective, and you can decide if this was one of my mistakes.

What does PassThrough really do? It tells the keyboard hook not to swallow the trigger event. Therefore it's a directive to the keyboard hook.

Every other keyword you write in a defintion (including If) gets executed by the interpreter after the hook finishes. PassThrough is a different kind of keyword. It's the only directive in the entire script language that gets executed by the hook.

The hook finishes before the interpreter begins. Therefore, PassThrough must execute before everything else you write in a hotkey definition.

In particular, PassThrough must get executed by the hook before the interpreter evalutes If.

Originally I thought users wouldn't have to understand this. I thought I could hide these facts from them and make things simpler. But during HotkeyNet's beta test it turned out that PassThrough was a major source of confusion.

So I made a small change to the script language to try to convey the idea to people that PassThrough always executes earlier than everything else.

I added a syntax rule -- which is enforced by the parser -- that requires PassThrough, if it's used at all, to be the first statement in a definition.

I thought this was a clever solution to the problem because everybody assumes scripts execute from top to bottom, and the parser would automatically force them to realize that PassThrough executes first. They wouldn't have to read this in the documentation. The parser would force them to do it correctly by means of an error message.

But as you can see from your own experience, this didn't work. You thought you encountered some sort of problem. Perhaps it would have been better if I had made a completely different syntax for PassThrough.