Hotkeynet comming back?

[Erron]

Anyone heard if Freddie is bringing this back??

http://hotkeynet.com

[Freddie]

HotkeyNet can still be downloaded from the website, and people are welcome to use it.

www.hotkeynet.com

[mikedoggy]

ive started useing it. i really like the possibilities. i havent fully gotten into it since im awaiting my ram before i start my 6th account so i dont want to have to rework macros.

i plan on it being a very integral part of how i play.

[Freddie]

Glad to hear that, Mike. I'm looking forward to hearing what you think about HotkeyNet after you've used it some more.

www.hotkeynet.com

[yvette]

i used the tool back in my daoc days and what freddie coded is awsome.

its a very powerfull tool for multiboxers !!



edit:

i used it for 6 toon boxing and never had problems with it

[Freddie]

Glad to hear it, Yvette. Thanks for the kind words.

www.hotkeynet.com

[Dusty]

I started using hotkeynet yesterday and really like it so far. Havent had time to really tweak everything out yet but looks like it has plenty of potential.

[yvette]

thats what i said :)

freddie did a good job on hkn

[Katharsis]

I've got Hotkeynet set for two PCs and it works fine if I use a key combination directly from the keyboard. It is not reading key combos sent by G15 or Ergodex macros. Should that be the case?

[Freddie]

Glad to hear it works fine with your two keyboards.

As for G15 and Ergodex macros, I don't have a G15 or Ergodex here so I can't test to see exactly what is happening. But one possibility is that the G15 and Ergodex create macros by "injecting" keystrokes, same as HotkeyNet. If this is the case, then by design, HotkeyNet would not ouput a macro of its own in response to keystrokes in the G15 or Ergodex macros.

www.hotkeynet.com

[yvette]

i used the g15 in combination with hotkeynet and it worked perfect

maybe you are doing something wrong.

[Freddie]

I just added a new feature to HotkeyNet that was requested by somebody who plays Dark Age of Camelot.

It's now possible to define hotkeys that execute hotbar commands in that game when the game is in the background. (Use the background_setfocus command in build 30.)

www.hotkeynet.com

[Freddie]

I added another new feature today (in build 32) -- a rename command, so windows can be renamed with hotkeys. Makes it a lot easier to launch multiple copies of games and get set up.

[yvette]

2 very very nice features !

[dRiN]

I have been testing this software last night but it gave me some errors on the config file I wrote to pass keys to multiple windows hosted on different computers. The syntax examples on your site are nice but I have some problems getting them to work correctly for my setup.

Is there a place where I can find more details on configuration and how to use it? Or should I start a topic on this forum for support?

I have looked at the forum for your software but it was really lacking the information I was looking for.

ps. This is my first post on this site. I have been dual / tripple boxing for a long time now. And after seeing some of the videos and the power behind 5 boxing I have started with that also. Mad respect for all multiboxers out there. Everytime people start moaning about me multiboxing I just refer them to this site. Most of the time they give positive feedback after seeing it has such a big community : )

[Freddie]

Is there a place where I can find more details on configuration and how to use it? Or should I start a topic on this forum for support?
I'd suggest making a new thread here. Please feel free to quote your hotkey definitions and explain exactly what you want to do.

If you prefer, you can ask instead in the HotkeyNet forum. I'll answer questions in either place. The reason why there's no info in the HotkeyNet forum is because it's new, and nobody has asked a question there yet.

www.hotkeynet.com

[Katharsis]

Hey! Thanks for making this available to us. The only problem I am having now is when I forget to check "Hotkeys are on". *blush*

[Freddie]

I'm the one who should blush, not you. :) If you're having a problem, it's a sign that I need to design the program better to make things easier.

In this case, it sounds like the program needs to indicate more clearly whether hotkeys are off or on. For example, the tray icon should turn gray when hot keys are off. I just made that change in build 38. This will help a little. Please let me know if you can think of other changes to make it even clearer.

Thanks for the feedback.

[Katharsis]

Feature request: A button to clear the text in the windows that show keys sent/received.

You state on P3 of the instructions that However, if you change a hotkey file while HotkeyNet is running, you need to load the file manually so HotkeyNet sees the changes.

If I make changes to the text file while Hotkeynet is running then Windows won't let me save changes, stating the file is in use. So, I have been making the changes, shutting down Hotkeynet, return to text file and save changes, start Hotkeynet. Phew! I must be doing something wrong, eh? When I do that I frequently get the error below and have to restart Hotkeynet 2-3 times. Then it works flawlessly. :D

Feature request: Make it so my alt's pet never does that again.


1

[Freddie]

Feature request: A button to clear the text in the windows that show keys sent/received.
What's the reason for that?


If I make changes to the text file while Hotkeynet is running then Windows won't let me save changes, stating the file is in use.
This is a new bug that you just found, and I just fixed it (I hope) in build 39.

Edit: I think the bug described in the next two sentences has been fixed in build 40. However there is a different bug which I haven't fixed yet that sometimes causes errors when HKN loads a hotkey file in place of another one which was already in its memory. Until I fix this second bug, you should close HKN after you load a changed hotkey file and then reopen HKN.


When I do that I frequently get the error below and have to restart Hotkeynet 2-3 times.
The need to restart HKN several times before it connects is a different bug. It's not related to hotkey files. I think you might be seeing it more often in that situation because it may occur more often when you quickly close and reopen the program.


Then it works flawlessly. :D
At last, a tiny ray of sunshine in this dismal list of bugs. :)

[Freddie]

So, I have been making the changes, shutting down Hotkeynet, return to text file and save changes, start Hotkeynet. Phew! I must be doing something wrong, eh?

You can get some rest now because I just fixed the bug that caused problems when you loaded a new hotkey file. At least I think I fixed it. :)

It should be possible now to change the hotkey file and reload it without closing HotkeyNet.

But just in case I didn't really fix the bug, please keep an eye out for it. You'll know the bug is still there if, after you load a hotkey file manually, a hotkey doesn't perform the actions you assigned to it or performs different actions.

[Katharsis]

Feature request: A button to clear the text in the windows that show keys sent/received.
What's the reason for that?

It was a casual request. While learning the program I would have the Hotkeynet window open on each computer. I would send the same command several times to see what was going on. I had the client respond with something like "Whee, it worked". After several lines got repeated it became hard to tell if a new entry had been made or not. So a button to clear the slate would be a convenience. It is certainly no problem to drag-select and delete.

I'm very pleased with the program and the well designed website with good tutorials. I'm two-boxing, using Hotkeynet with a Nostromo N52 and Multiplicity for mouse/ keyboard switching.

[Freddie]

...So a button to clear the slate would be a convenience.
Thanks for explaining. I think you're right, that sounds like a good idea, so I just added a "clear" button in build 41. Let me know if it works okay.


I'm very pleased with the program and the well designed website with good tutorials. I'm two-boxing, using Hotkeynet with a Nostromo N52 and Multiplicity for mouse/ keyboard switching.
I'm very glad to hear that. And I'm impressed that all three things are working together (N52, Multiplicity, HKN).

[Freddie]

3

That's a great bug report, thank you very much. I just fixed that problem in the latest build, number 42. At least I think it's fixed. The program seems to connect now just about every time it starts.

Unless I've lost track, that takes care of all the bugs you reported so far. Thanks a million for your help. If you find more bugs, or have any other suggestions, please let me know.

[Katharsis]

I've got a new computer arriving today and will put Hotkeynet to the test with Vista. I haven't installed the new build yet but I did think of a couple more things.

1. The last time I clicked "About" from the menu the dialog mentioned a thirty day expiration. ?(

2. I can see where I would end up with multiple text files for different uses. It would be nice to be able to see which text file is loaded. I assume that when I load a new file it flushes the old one, yes?

3. When I want to shut down Hotkeynet I get the Hide/Shutdown dialog. Could you place a "Do not show this again" checkbox there or offer a Shutdown button next to the Hide button on the main window?

4. Here is a macro I use occasionally:


/console cameraBobbing 1
/console cameraBobbingFrequency 0.01
/console cameraBobbingSmoothSpeed 0.0028
/console cameraBobbingLRAmplitude 0
/console cameraBobbingUDAmplitude 10000
Rather than take up valuable macro space it seems Hotkeynet could handle this nicely like so?


<hotkey Ctrl Shift D>
<Sendpc local>
<ENTER>/console cameraBobbing 1<ENTER>
<ENTER>/console cameraBobbingFrequency 0.01<ENTER>
<ENTER>/console cameraBobbingSmoothSpeed 0.0028<ENTER>
<ENTER>/console cameraBobbingLRAmplitude 0<ENTER>
<ENTER>/console cameraBobbingUDAmplitude 10000<ENTER>
Just wondering if a succession of hard returns like that would be asking for trouble.

[Freddie]

I've got a new computer arriving today and will put Hotkeynet to the test with Vista. I haven't installed the new build yet but I did think of a couple more things.
Nice. What did you get?


1. The last time I clicked "About" from the menu the dialog mentioned a thirty day expiration.
That only means that the particular build expires. When that happens, just go to the website and download the current build. This is a way of forcing people to run current builds, which is important for beta testing to find new bugs -- sort of a paleolithic version of an autoupdater.


2. I can see where I would end up with multiple text files for different uses. It would be nice to be able to see which text file is loaded. I assume that when I load a new file it flushes the old one, yes?
That's a good idea. I'm planning to design a completely new interface for the program after the feature set is complete, and I'll include this idea. And yes, the old file gets flushed. (This is true today because one of your previous comments got me to fix a bug yesterday that prevented a complete flush.)


3. When I want to shut down Hotkeynet I get the Hide/Shutdown dialog. Could you place a "Do not show this again" checkbox there or offer a Shutdown button next to the Hide button on the main window?
Yeah I'll do something about this. But I have to be careful not to do anything to confuse new users. Sometimes there's a tradeoff between ease of use for old users and avoiding confusion for new ones. Especially with this program, where there is so little visible interface, I want to be careful about that.


Just wondering if a succession of hard returns like that would be asking for trouble.
Why would it be trouble? It's no trouble for HKN -- it doesn't care which keystrokes or how many you ask it to inject. It may be trouble for the game but I don't play WoW so I can't comment on that. (I should probably restart my WoW account to get familiar with it -- I never got past level 12.)

In general, one fact that you always need to keep in mind is that HKN injects the entire macro at lightning speed, but the game can't always accept keystrokes that fast, and some of the keystrokes may get lost. If that happens you need to insert <wait ####> commands into the macro to give the game time to get ready for the next keystroke. Placing <wait ####> commands and adjusting the number in them is a matter of trial and error.

[Darm]

Is there a command or something I can put in the config file to tell Hotkeynet to pause?

I can right-click on the icon when it's in the system tray to pause, I'm looking for a way to arrange it so I can press a key to do the same thing. Thanks for the help!

[Freddie]

I'm looking for a way to arrange it so I can press a key to do the same thing. Thanks for the help!

A number of people have asked for this, and I'm going to try to add it to the program. Unfortunately, it's difficult because of the way the program is designed, and it may take me a while. Thanks for the suggestion.

[HomersDonut]

I'm looking for a way to arrange it so I can press a key to do the same thing. Thanks for the help!A number of people have asked for this, and I'm going to try to add it to the program. Unfortunately, it's difficult because of the way the program is designed, and it may take me a while. Thanks for the suggestion.

I was thinking about this some more last night. Perhaps change it so that instead of shutting down the keyboard hook, but validates the hotkey against an active/inactive list before firing off the macro. As for incorporating that into the script, there could be a couple of ways.

<Hotkey X Switchkey> could define a single toggled hotkey, while
<Hotkeygroup Name SwitchKey> ... </Name> could encompass a group of keys with a common toggle.
To toggle on/off actual windows or instances, the Switchkey could be set in the <rename> or <rename_from_path> commands.

Finally, would there be much demand for <HOTKEYDOWN>and <HOTKEYUP>definitions? My reason is that while WoW's /follow command is cancelled fairly easily, it isn't the case in EQ2 where you can still use left & right movement to circle around your /follow target. Having to repeatedly press an arrow key to have the scout inch around doesn't feel or look very cool ;)

Call it a wishlist ;)

And for the record, I've been testing this with 2 EQ2 instances on 1 box. The <sendwin> command will work ok, but only with a sufficient <wait> (as you mentioned above with the WoW console). Natively, the <sendwinM> does not work with EQ2 but does under Innerspace (I know, I caved ;( ) That being said, I've seen some very funky key translations happening. For example, a <numpad_minus> key that injects an <equals> to both instances comes though as a <0> on the background instance. Really not sure what is happening there ?(

Cheers :)

[Freddie]

I added on/off commands to the program today, since several people asked for them. There are three new keywords that you can use in hotkey definitions:

turn_hotkeys_on
turn_hotkeys_off
toggle_hotkeys

Of course you don't need all three. If you like the idea of a toggle, you can use that one by itself. Otherwise make a pair of hotkeys with the other two. All of these new keywords can be used on the local machine like this:


<hotkey F1>
<sendpc local>
<toggle_hotkeys>

or on a remote machine like this:


<hotkey F1>
<sendpc 192.168.1.102>
<toggle_hotkeys>

In all cases, "on" and "off" refer to whether pressing keys on the "sendto" pc will generate a macro. They do not afffect whether that machine receives macros from some other machine. If you want a pc to stop receiving macros, you need to turn HotkeyNet off on that machine.

I didn't have time to test these new keywords carefully so I'd appreciate it if you'd knock them around a bit and look for problems. Thanks.

[Freddie]

3. When I want to shut down Hotkeynet I get the Hide/Shutdown dialog. Could you place a "Do not show this again" checkbox there or offer a Shutdown button next to the Hide button on the main window?
I did this today. It's in build 44. Thanks for the suggestion.

[HomersDonut]

I figured out a workaround to be able to stop transmitting to an instance -Have the instance stop listening. I bound a hotkey to rename an instance from 'Box1' to 'Box1Off'. That way you prevent that instance from recieving any keys as well as having an on/off indicator via the window's titlebar.

Just thought I'd share this :)

[Freddie]

That's a great idea. Unfortunately, if I remember correctly, whenever HotkeyNet fails to find a window, it cancels the rest of the macro on the receiving PC, so this could affect not only the renamed window but also other windows defined in the same hotkey.

I'll check the code and if I'm remembering correctly, I'll change the program so this idea works all the time.

[Katharsis]

Great job, Freddie! I've got Hotkeynet running fine on Vista Ultimate and XP. Thanks for the quick respone on requested changes.


I'm planning to design a completely new interface for the program after the feature set is complete,

Will there be skins? *snicker*

[kandore]

First of all, I really love the program. I've read through your website tutorial and it all seems to make sense, but on my first test macro I'm running into a problem. On my client computer I have EQ2 running titled just as EQ2. I have all of my spells that I need on my hotbar assigned to a number or combination of CTRL/ALT and a number. I plan on using my server computer to run one toon using regular macros from the in game hotbar, but to be able to press F1 through F12 to access spells and macros on the second computer. My first hotkey from my server computer looks like this (with my actual IP address instead of the words)...

<hotkey F1>
<sendpc ipaddress>
<sendwin EQ2>
<keydown>1<keyup>

I keep getting an error in HotKeynet on my client computer that says
"Unknown command or keyname:."
then after I hit OK it says the same thing again, but continues to cast the spell in EQ2. I wouldn't mind the error except I have to physically click OK twice before the spell gets cast, and by that time I'd probably be dead, lol. Am I making a silly syntax error or something like that? Thanks for your help, can't wait to use the program more!

[kandore]

Ha, nevermind. It didn't like my keydown and keyup commands. I just told it <1> instead and it worked just fine.

[Freddie]

Thanks for the kind words. I'm glad you got it figured out. I'm also glad you told me about the problem because it shows a weak area in the program that needs to be improved. What should have happened, when you put <keydown> in your file, is that the program should have told you:


"keydown" requires the name of a key inside the brackets like this: <keydown F3>
If the program had told you that, the confusion could have been avoided. So I need to add stuff to the program that will check your hotkey files and tell you how to fix the mistakes. And in fact I worked on that today.

By the way, these two commands together:

<keydown 1><keyup 1>

mean "press the 1 key down, then release it." Which is the same thing as simply typing 1. Which is what you did when you simply wrote <1>. In fact, since 1 is an ascii character (a printable character) you could have simply written 1 without brackets. But <keydown> by itself doesn't mean anything to the program.

[Freddie]

Great job, Freddie! I've got Hotkeynet running fine on Vista Ultimate and XP.
Thanks a lot. Very glad to hear it.


Will there be skins? *snicker*

Well... let's just say it's not close to the top of the to-do list. :)

[Freddie]

I've been busy the last few days adding a big new ability to the program. (This feature isn't available yet in the current build... I need to test it a little bit more.) I've also expanded the documentation. There's now a reference section here:

HotkeyNet Reference ('http://www.hotkeynet.com/ref/functions.html')

I've also spent time writing a new parsing system that will check hotkey files when you load them. It will point out mistakes to the user and give hints for correcting them. It may be a while before this new error detection is visible in a public build, because I have to rewrite all the existing commands so they make use of it.

[Freddie]

I was thinking about this some more last night. Perhaps change it so that instead of shutting down the keyboard hook, but validates the hotkey against an active/inactive list before firing off the macro.
Sorry it has taken me so long to reply to this post. Thanks for the suggestion. As you know the feature has been implemented so this topic is moot, so I'll just say that in a general way, your suggestion describes what had to be done, but because of the way the program was written, implementing this required changing some things in a way that exposed one encapsulated part of the program to another part. Also an even bigger problem was that the way the program had been written, the commands weren't interpreted until execution time on the receiving pc. But in order to implement this feature, the commands needed to be parsed and understood on the sending pc when the macro file was loaded, prior to execution of the macros. So I had to either write code that duplicated the interpreter's function so the file-reading code could do that, or else I had to modify the interpreter so part of its capability was available at file-reading time. Because of the possibility of introducing bugs due to loss of encapsulation,and because of implementation details, I was reluctant to do these things. But anyway it's done now and seems to have turned out okay.


As for incorporating that into the script, there could be a couple of ways.

<Hotkey X Switchkey> could define a single toggled hotkey, while
<Hotkeygroup Name SwitchKey> ... </Name> could encompass a group of keys with a common toggle.
To toggle on/off actual windows or instances, the Switchkey could be set in the <rename> or <rename_from_path> commands.

Toggle a single hotkey -- this makes me worry about user confusion and support problems. Let's look at things from the viewpoint of the average new user writing new hotkey definitions, trying to get them to work with their game, having difficulties -- and now on top of wondering if they've written the definition correctly, and wondering if they've understood the documentation, and wondering if hotkeynet is bugged, and wondering if this particular feature works with their particular game -- now there's the added complication that they might have turned the hotkey off without realizing it. I dont know if you've ever supported published software (been in the position of getting questions and complaints from customers) but from my position, anything that makes things more complicated and confusing for users can be a headache.

I suppose maybe I could handle that problem with a check box on HotkeyNet that forces everything on, no matter what.

Groups of keys -- At some point it will be a good idea to handle groups of keys. Not only for toggles but for such things as having them on when a particular window is in the foreground. So I think groups have to be dealt with in the same context as conditional execution depending on the foreground window. I think Autohotkey handles this with an "if window is in foreground" construct. HKN eventually needs that sort of thing, and however groups are implemented, their on/off state should be linkable to it. Also I'm planning to add clickable panels of buttons on the screen that will be changeable as different windows come to the foreground. That involves groups of keys too. WhatI'm trying to say is that all these things are tied together, and I can't implement one piece of them until the whole thing is planned.

the Switchkey could be set in the <rename> or <rename_from_path> commands -- I think you're right that eventually the program should have a feature like that, but I'm not sure it would be a good idea to implement it as an argument in those existing functions. The problem is that a user who is looking for a way to turn off keys for a window is going to look through the documentation for a function with a name like "turn off hotkeys for a window." Their eyes will bounce right over "rename" because renaming doesn't seem to have anything to do with turning off hotkeys.

Also, there's a general question about the design of software interfaces about whether functions in an API should do more than one thing. I'm pretty firmly in the camp that says no. My opinion is, a function should perform one action that is clearly indicated by its name. Why? Because for most people, this makes the API much easier to understand and use.


Finally, would there be much demand for <HOTKEYDOWN>and <HOTKEYUP>definitions? My reason is that while WoW's /follow command is cancelled fairly easily, it isn't the case in EQ2 where you can still use left & right movement to circle around your /follow target. Having to repeatedly press an arrow key to have the scout inch around doesn't feel or look very cool ;)

I'm not sure I understand this idea. Do you mean a command that would have the effect of holding the movement key down, and another command that would stop that? If so yes, that needs to be done. It's on the list.


Natively, the <sendwinM> does not work with EQ2 but does under Innerspace (I know, I caved ;( )

Did you try <sendwinM> with <background_setfocus>?

Can you give me a link for Innerspace? I don't know what it is.


That being said, I've seen some very funky key translations happening. For example, a <numpad_minus> key that injects an <equals> to both instances comes though as a <0> on the background instance. Really not sure what is happening there ?

I need to completely rewrite all the keystroke stuff -- it was written very hastily -- but the intention with HKN is that it always merely sends Windows's "official" virtual key codes. And whatever translations are done, are done by Windows, taking into account your keyboard device driver and locale settings and whatever else Windows takes into account. So any mistranslation is either a bug on my part or just Windows being Windows.

Maybe when I rewrite it, I'll include more diagnostic stuff so you can get a better idea what's happening, if possible

Cheers,

Freddie

[Simulo]

quick question:

how would one script a command so that ' w ' is sent to the other window until the ' w ' key is released

ie: i want both of my characters to move at the same time w/o using a follow command

[Freddie]

You can't yet, but it's on the list of things to add.

[Freddie]

Build 48 is now available. New stuff:

-- Mouseclicks. You can now make hotkeys that click windows or the screen. There are many options for positioning the clicks.

-- The bug that caused single keynames like <F3> to be mistranslated with SendWinM and SendWinMF has been fixed. (However you still cannot use multiple keynames like <ctrl F3> in output. I'll fix that soon.)

More info about MouseClick here ('http://www.hotkeynet.com/ref/mouseclick.html')

Download HotkeyNet 48 here ('http://www.hotkeynet.com/p/download.html')

[HomersDonut]

Hi Freddie.

I quickly tried build 48 and <sendwinMF> with EQ2 last night, but that still doesn't work. Does <sendwinmf> require <set_backgroundfocus> too?

[Freddie]

Thanks for testing that and letting me know.

You don't need background_setfocus with SendWinMF because it's already built in. (SetWinMF consists of SendWinM, background_setfocus, and background_killfocus combined in a single command. The F stands for focus.)

I'm not surprised to hear that SendWinMF doesn't work with EQ2. When I wrote that command, I had DAOC running, and I kept testing different combinations of Windows API functions until I found one that works with that game. But I wouldn't necessarily expect it to work with any other game. In order to stand a chance of creating commands that work with other games, I probably have to do the same thing individually with each one.

[kandore]

Oh good, someone else is using this with EQ2. Have you had any issues with keydown and keyup? When I try to use anything that requires my other pc to hold down a key nothing happens. The copy of hotkeynet running on my other computer shows that it received the command and the keys it's pressing, but my game doesn't do a thing.

I have some decent macros taking up the number keys but it would be nice if I could use the whole range of the hotbar. Hopefully this is just me and maybe installing the newest version will fix it.

[Freddie]

I'm working on that stuff right this minute. There will be a new build soon. I made a mistake when I told people to use <KeyDown> and <KeyUp>, because when I started working on them again yesterday, I realized that they were incomplete in the versions that are on the website. In those versions, at best, they will only work with SendWin. Sorry for my mistake.

Like I said, there will be a new build soon with all this stuff (KeyUp, KeyDown, and combo keys like <shift alt F3>) workng with all Send commands.

[kandore]

Woohoo, thank you. I definitely appreciate all of the work you're putting into it. I look forward to the future builds :)

[Freddie]

The new build (49) is now on the website. I decided to do this work in two stages. First for SendWin, then later after this first round of changes is debugged, I'll do the other Send methods.

I had to change a lot of code internally, so I probably created some new bugs. It would be really helpful if people would download the new build and kick the new stuff around a bit to flush the bugs out. Changes include:

(1) You can now use multiple key labels like <ctrl F3>, <rshift lalt 7>, etc., for output.

(2) Added <KeyDown scancode ex> and <KeyUp scancode ex>. The purpose is to give the user exact control over which key gets output.

(3) Fixed <divide> bug.

A note about the first change. While I was testing it, I found that HKN types keystrokes so fast that some programs don't have time to see the shift keys. With DAOC, for example, instead of writing this:

<shift 2>

I had to write this:

<keydown shift><wait 100>2<wait 100><keyup shift>

...just to slow things down enough for DAOC to see all the keys. But with other programs, <shift 2> works fine.

[kandore]

I played with the newest build for a few hours tonight on EQ2 and I didn't run into any problems. I did have to use the <wait> method with the keyup and keydown commands, but it did work. Thanks for the super quick update.

[Freddie]

You're welcome, and thanks for the super quick report. Do you think I should build in some kind of automatic delay so people don't have to use <key up><wait> etc?

[Rimmel]

Not to offend anyone with my stupidity :P

...but how do you Create a Hotkey File?

I'm just now attempting to dual box, and this softwares' Server to Client connection set up was so simple that I really look forward to using this more in the future.

[Freddie]

...this softwares' Server to Client connection set up was so simple that I really look forward to using this more in the future.
Thanks! That's just about the biggest compliment I can imagine for a piece of software.


...but how do you Create a Hotkey File?
Try this page. ('http://www.hotkeynet.com/p/doc3.html')

And this one. ('http://www.hotkeynet.com/p/doc4.html')

[HomersDonut]

Do you think I should build in some kind of automatic delay so people don't have to use <key up><wait> etc?Doing so would certainly simply the hotkey file, making it simpler to debug and easier to maintain. Oh, and just about to try out build 49 myself :)

[Freddie]

50 is up. :)

[kandore]

Wow you're a machine! I'll start using the new build tonight. I might be raiding with my guild...but if not I'll get in some boxing time. Also, yes, I agree that adding in the wait time directly to the keyup and keydown commands would be helpful. I didn't see that in the notes for build 50 so I'm assuming you didn't add it already.

[HomersDonut]

I played with the newest build for a few hours tonight on EQ2 and I didn't run into any problems. I did have to use the <wait> method with the keyup and keydown commands, but it did work. Thanks for the super quick update.Unfortunately no luck for me when running with 2 instances on 1 PC. Are you running between 2 PCs or a single?

[kandore]

I'm running with 2 PCs so I only ever need to use sendwin, otherwise I imagine you'll run into some problems since Freddie hasn't completed the fixes for sendwinM or sendwinMF (right Freddie?).

[Freddie]

Can you send to EQ2 in the background with AutoHotkey? If so, send me some AutoHotKey macros that work, and I'll duplicate the functionality in HotkeyNet.

[Freddie]

I'm running with 2 PCs so I only ever need to use sendwin, otherwise I imagine you'll run into some problems since Freddie hasn't completed the fixes for sendwinM or sendwinMF (right Freddie?).
Well, I wrote those two functions to send to DAOC in the background, and it took quite a bit of experimenting to make them work. I wouldn't necessarily expect them to work with any other game. In order to send to other games in the background -- which might not always be possible -- I might have to repeat that process for each game and add a new command for each game.

I just got an idea to make this practical. Like I said, if anybody has managed to use AutoHotKey to send to some other game in the background, send me the macro definitions, and I'll duplicate the abilities in HotkeyNet.

[HomersDonut]

Can you send to EQ2 in the background with AutoHotkey? If so, send me some AutoHotKey macros that work, and I'll duplicate the functionality in HotkeyNet.
To date I've only been able to send to a background EQ2 instance (on the same PC) when it was running under Innerspace. This applies to Octopus, Autohotkey, Keyclone and Hotkeynet. When running the 2nd instance on other hardware, all of these (except Keyclone) worked fine without innerspace. That being said, all had issues with sending modified keys remotely.

As for an example autohotkey script, sorry. I haven't had a workable or even test one for some time now.

Just as a final thought, I did have some limited success with HKN and switching foreground focus quickly between the 2 instances.

[Freddie]

Sending to EQ2 in the background seems to be quite a challenge. Hmm. I just installed it and opened a trial account so I can give it a shot. :)

[Freddie]

Build 52 is up. Changes:

-- Added a function for sending to background DAOC windows.

-- Removed underscores from function names.

-- The program will tell you when it loads your hotkey file whether you need to change any functions names.

[kandore]

downloading it now and finally getting to play. The week has been busy. I'm going to mess around with the mouseclicks a bit since I haven't tried them out yet.

[Freddie]

I'm downloading updates to EQ2 so I can try sending to it in the background. :)

[kandore]

I think I ran into an issue with mouseclicks in EQ2. I made macros in game to target the different group member positions, and I put them in a section of my hotbar that doesn't have hotkeys so that I would have to click on them with my mouse. Here is my code:

<hotkey NUMPAD_END>
<sendpc ip address>
<sendwin EQ2>
<MouseClick Left Window 1025 900 NoRestore>

I used guess and check with NoRestore to position my mouse correctly, and it definitely moves to the right spot, but it doesn't actually click it. I tried it as <MouseClick 1025 900 NoRestore> and also with adding in the optional other fields. Thanks for checking into eq2 personally...we're a mess :)

[Freddie]

> Thanks for checking into eq2 personally...we're a mess

:D

I'm looking at MouseClick in EQ2 now.

[Freddie]

I just returned from exploring the depths of MouseClick. I found your bug plus another bug I didn't suspect plus a mismatch between the code and the documentation. I fixed that stuff but I'm scared to think of what else might be lurking in the other parts of MouseClick that I didn't check. :)

Build 53 is on the website now. It clicks properly on EverQuest using this simple hotkey that doesn't move the cursor. I didn't test in any other way so you'll probably be getting back in touch with me real soon as you uncover more problems. :) Thanks a lot for finding the bug.


<HotKey F1>
<SendPC 192.168.1.102>
<SendWin EverQuest>
<MouseClick window nomove>

[kandore]

It sort of works now... Right now it positions the mouse correctly as before, but it seems to be clicking before making the move. I'd leave my mouse highlighted over a spell, use my mouseclick command, and it'd move to the correct spell but click the previous one before moving. Is there a way to write a command just for the mouse to move? Then I could put the two together where it moves in the first step and clicks in the second. It's not a huge problem because I don't definitely need this to work to be able to play, but if I start to play more than two toons it'd be nice to switch for cures and casting spirit of the wolf on all group members with a single click.

[Freddie]

Thanks for the report. Yes I'll add a way to move the mouse without clicking. But In addition to that, this bug definitely needs to be fixed.

Could you post the hotkeydefinition so I can try to duplicate the exact problem?

[Freddie]

It sort of works now... Right now it positions the mouse correctly as before, but it seems to be clicking before making the move.
I think I fixed this. It seems to be a timing problem just like the shift key issue. HotkeyNet was asking Windows to perform the move and the click in the correct order, but Windows apparently takes longer to move than to click, so EQ2 was seeing the events in reverse order.

To fix the problem, I had to insert a delay between the move and the click. This time I made the delay automatic instead of something you have to write in the hotkey file The default length of the delay is 15 milliseconds. If this is too short, you can make it longer on the Settings panel.

The fix is in build 54 which is on the site now.

Please let me know if this fixes the problem.

(I didn't forget about the MouseMove command -- I'll do it after we fix this bug, because I don't want the new command to be a substitute for a real fix.)

[kandore]

90% of the time it does them in the right order...oh wait, I increased the delay to 50 and now it works. The default was 15 and that was a little to little. I'll keep playing with it just to be sure.

[Freddie]

Thanks. What's the CPU specs in that machine? Brand, cores, GHz?

[kandore]

Main Computer (server)
AMD Athlon 64 X2 Dual Core Processor 4200+
2.20 GHz 2 GB RAM
NVIDIA GeForce 6600 in the PCI Express slot
I play w/ two monitors on my main computer and one on my older one. My gf just kicked me off the older one in order for her to do homework...so I can't give you the exact specs. It's probably 5 or 6 years old now since I got it when I was a senior in high school. I think it has 768mb of RAM and it uses some AGP card. My newer one is about 2 yrs old now. I really want to upgrade again soon. Get some SLI goodness going. EQ2 is so freakin demanding.

[kandore]

I think I ran into a problem the other night, but I'm at school now so I can't post the exact code I was using. I know it used to work a few builds ago when I first wrote the macro. Basically I tell my client computer to press key 4, wait 100ms, and then use the keydown alt/wait/key/wait/keyup method. All of my keydown and keyup commands using ctrl work fine, but this one with alt is having problems. I guess I should have tested it out more last night, but it was only affecting a minor spell and I wanted to level, hehe. If i get to play 2nite I'll post the exact code and run some other tests with alt...but if you find any issues with keydown/keyup and alt let me know. Thanks!

[Freddie]

Why don't you post it when you get home and i'll take a look at it.

[mana333]

I'm on a wireless connection and I get dropped and picked up several times a day (looking into the issue). The problem I have is that the client won't recognize that the connection has been dropped. It still reads as if it is still connected to my server when in fact it is not. The server recognizes the drop and gives the message accordingly. What I have to do is go into the room with the networked computer and manually restart hotkeynet. Is there a way to fix this?

[zuvio]

I am trying to multibox 6 ffxi accounts on two PC's, so naturally I ran into the problem of keystrokes not being broadcasted to non-active FFXI windows. HotKeyNet offers me some solution to this problem, but it's not 100%. I use the method of <sendwin FFXI account> to send keystrokes to all my running windows with the downside of having HKN switch between them and restoring afterwards.

My basic Hotkey file looks like this:


<hotkey 1>
<sendpc local>
<SendWin Zuvio>
<wait 70>
<Lctrl 1>
<wait 70>
<sendwin Carsomyr>
<wait 70>
<Lctrl 1>
<wait 70>
<sendwin Aella>
<wait 70>
<Lctrl 1>
<wait 70>
<restore>

This hotkey sends the key combo ctrl+1 to all active windows. In FFXI, you access your macros through the combinations of ctrl+0-9 and alt+0-9. So all my windows active macro ctrl+1 with the hotkey 1.

So far, all the other <send> commands do not work in this game. I have tried the same macro with <sendwinM> + <SetBackgroundFocus> and <KillBackgroundFocus> and <sendwinMF>. These hotkeys do not send any keystrokes to any window. This is very annoying while playing the game because 1: it flips the windows which sucks and 2: it creates some lag in sending the commands. I would be very happy if there was some way of sending keystrokes to non-active windows simultaneously without having to flip through focus.

Are there any future plans of incorporating FFXI into the program, such as the DoaC send command? I would really appreciate that.

But for now, HKN allows me to multibox this game on two PCs, so I am extremely grateful for that already.

Macros such as this one below have no effect, they do not send keystrokes to the windows, none of them :(


<hotkey F1>
<sendpc local>
<sendwinM Zuvio>
<setbackgroundfocus>
<wait 100><LCtrl 1><wait 100>
<killbackgroundfocus>
<sendwinM Carsomyr>
<setbackgroundfocus>
<wait 100><LCtrl 1><wait 100>
<killbackgroundfocus>
<sendwinM Aella>
<setbackgroundfocus>
<wait 100><LCtrl 1<wait 100>
<killbackgroundfocus>

[Dareon]

Im finding a program that works for free and i found this post and was wondering how this works? And yes i found the guide on the websites but i really didnt get it... There you didnt tell where you should put those hotkeys etc? Im sorry im noob but im an amateur :D

[Freddie]

I'm on a wireless connection and I get dropped and picked up several times a day (looking into the issue). The problem I have is that the client won't recognize that the connection has been dropped. It still reads as if it is still connected to my server when in fact it is not. The server recognizes the drop and gives the message accordingly. What I have to do is go into the room with the networked computer and manually restart hotkeynet. Is there a way to fix this?
This doesn't happen on my network, so I'm going to need your help in order to try to find the cause of the problem. My first thought is that this problem could be caused by any one of three things -- my use of the Windows socket API inside HKN. or the way Windows handles socket connections, or your router. If anybody has any ideas, please chime in.

Could you do a couple of little experiments? First, start both copies of HKN. After they connect, close (exit) the server copy of HKN by clicking with the mouse. Does the client HKN correctly notice that the connection is gone?

Second, wait for the problem to occur as you describe. When it happens, instead of walking into the other room and restarting the client manually, just let the cliient run for a while. Wait for a while -- up to an hour, say -- and see if the client notices on its own that the server is gone. (The reason I'm asking you to do this is to see if it's a question of a time-out value that presumably could be set differently.)

[Freddie]

I am trying to multibox 6 ffxi accounts on two PC's, so naturally I ran into the problem of keystrokes not being broadcasted to non-active FFXI windows. HotKeyNet offers me some solution to this problem, but it's not 100%. Thanks for the detailed report.


My basic Hotkey file looks like this...

Those 70 ms delays really add up when you're running that many clients on a single PC. I certainly understand why you want to send the commands in the background.


So far, all the other <send> commands do not work in this game. I have tried the same macro with <sendwinM> + <SetBackgroundFocus> and <KillBackgroundFocus> and <sendwinMF>. These hotkeys do not send any keystrokes to any window...

There are two issues here. First, whenever you're trying to get a game to receive keystrokes while it's in the background, start off with a macro that sends a simple printing key like 1 by itself instead of a combination like <LCTRL 1>. I say this because when you try to specify the shift state -- in other words, when you try to send a combination like LCTRL 1, or ALT 1, or SHIFT 1 -- you introduce additional issues that make the problem much harder.

Second, I've been experimenting a bit with several games, trying to get them to accept keystrokes in the background, and each game has presented unique problems. So far the only games that I've gotten to work pretty decently are DAOC and WoW. (The WoW stuff is in my current work build which is not yet published.) Therefore it wouldn't surprise me if the send methods that are currently in HKN don't work with background FFXI even if you limit yourself to printing keys.


Are there any future plans of incorporating FFXI into the program, such as the DoaC send command? I would really appreciate that.



I probably won't play around with FFXI myself, but I plan to add some new low-level commands to HKN which will enable users to create new varieties of <sendwin> and experiment with them and try to find a version that works with their particular game. In other words, users will be able to do pretty much the same thing that I would do myself if I had time to try to find a <sendwin> method that works with their games.

Another thing that users can do to help is experiment with AutoHotkey. (I single out that program because it has a rich set of send methods and also because it's open source, so I can watch it execute in a debugger and see what it's doing.) If you can get AutoHotkey to send to FFXI in the background, I can duplicate the required functionality in HKN.

[Freddie]

Im finding a program that works for free and i found this post and was wondering how this works? And yes i found the guide on the websites but i really didnt get it... There you didnt tell where you should put those hotkeys etc? Im sorry im noob but im an amateur :D
The reason the instructions don't tell you where to put your hotkey file is because there's no special place. You can put it anywhere you like. (You can also name it anything you like.) When you click "Load hotkeys" on HotkeyNet's main screen, HotkeyNet asks you to show it where the file is.

[Draku]

Im finding a program that works for free and i found this post and was wondering how this works? And yes i found the guide on the websites but i really didnt get it... There you didnt tell where you should put those hotkeys etc? Im sorry im noob but im an amateur :DI'm using it for wow....and the latest version is robust, easy to install and easy to configure

[Dareon]

Could you give me a link where to get it pls?

[zuvio]

Thanks for the detailed report.

My pleasure :)


Those 70 ms delays really add up when you're running that many clients on a single PC. I certainly understand why you want to send the commands in the background.

I have to include those delays, otherwise the <sendwin> command goes too fast. FFXI has some inherent laggyness and if I use <sendwin> without ms delays, most characters won't do anything. Simply pressing ctrl to bring up the macro window has like a one second window delay in one FFXI account.


There are two issues here. First, whenever you're trying to get a game to receive keystrokes while it's in the background, start off with a macro that sends a simple printing key like 1 by itself instead of a combination like <LCTRL 1>. I say this because when you try to specify the shift state -- in other words, when you try to send a combination like LCTRL 1, or ALT 1, or SHIFT 1 -- you introduce additional issues that make the problem much harder.

Second, I've been experimenting a bit with several games, trying to get them to accept keystrokes in the background, and each game has presented unique problems. So far the only games that I've gotten to work pretty decently are DAOC and WoW. (The WoW stuff is in my current work build which is not yet published.) Therefore it wouldn't surprise me if the send methods that are currently in HKN don't work with background FFXI even if you limit yourself to printing keys.

I will attempt to send a simple /hi command using <sendwinM(F)>, but I doubt it would work, that would be too easy :D


I probably won't play around with FFXI myself, but I plan to add some new low-level commands to HKN which will enable users to create new varieties of <sendwin> and experiment with them and try to find a version that works with their particular game. In other words, users will be able to do pretty much the same thing that I would do myself if I had time to try to find a <sendwin> method that works with their games.

Another thing that users can do to help is experiment with AutoHotkey. (I single out that program because it has a rich set of send methods and also because it's open source, so I can watch it execute in a debugger and see what it's doing.) If you can get AutoHotkey to send to FFXI in the background, I can duplicate the required functionality in HKN.

Alright, I'll get AutoHotKey and see if I can send a command to background windows and report my findings. Funny thing is, I opted for HotKeyNet because it looked easier then AHK, but for the sake of multiboxing, i'll learn the program :D

Thanks for your reply!

[Freddie]

I have to include those delays, otherwise the <sendwin> command goes too fast.
I know you do. I was just making an observation that the delays are especially annoying when you have a lot of clients on the same machine because the delays happen one after another, so they add up. In comparison, if the clients were on separate machines, the delays would take place simultaneously. I'm not suggesting that you should buy more pc's -- I was just commenting on the situation.


Funny thing is, I opted for HotKeyNet because it looked easier then AHK, but for the sake of multiboxing, i'll learn the program :D
Heh, good point.

[zuvio]

I have managed to send keystrokes to both a non-active and an active FFXi account using the following code:


WinGet, polid1, ID, Zuvio
WinGet, polid2, ID, Carsomyr

#IfWinActive, Zuvio

F1::
ControlSend,,/p hi{enter}, ahk_id %polid1%
ControlSend,,/p hi{enter}, ahk_id %polid2%
return

This results in both chars 'typing' /p hi in there chat input screen whenever I press F1 when they main window 'Zuvio' is active. However: the {enter} key is not processed, thus /p hi remains on the chat input bar. The message never actually gets send to the chat window. This is consistent with the following piece of code:


WinGet, polid1, ID, Zuvio
WinGet, polid2, ID, Carsomyr

#IfWinActive, Zuvio

F1::
ControlSend,,{u down}{u up}, ahk_id %polid1%
ControlSend,,{u down}{u up}, ahk_id %polid2%
return

When I press F1 now, nothing happens. The u key, which is supposed to be a single key input to bring up my menu screen in FFXI, does not have any effect in game.

I will keep on trying and experimenting with other scripts to produce more results when necessary. Particularly I will attempt to send a 'Ctrl+ key' to both accounts to start a macro.

EDIT: so far, only {space} works in FFXI. Space brings up an empty chat input bar. {enter} etc do not work.


EDIT 2: Ok I think I have gotten something better. I have made a small script which will activate my first macro in-game which is normally activated by Ctrl+1. It's very simple:


#IfWinActive Zuvio

1::
Send {ctrl down}{1 down}{1 up}{ctrl up}

This macro works whereas


WinGet, polid1, ID, Zuvio

#IfWinActive Zuvio

1::
ControlSend,,{ctrl down}{1 down}{1 up}{ctrl up}, ahk_id %polid1%
return


does not work. For multiboxing purposes however, this blows :(

[Freddie]

That was fast. Great work. Just for purposes of understanding what's going on, could you modify the first script so {enter} is sent not by ControlSend but by Send? I might not have the syntax quite right but it would look something like this:


WinGet, polid1, ID, Zuvio

#IfWinActive, Zuvio

F1::
ControlSend,,/p hi, ahk_id %polid1%
Send {enter}
return

[Freddie]

Could you give me a link where to get it pls?

Sorry Dareon, a link for what?

[zuvio]

Your code was spot-on.


WinGet, polid1, ID, Zuvio

#IfWinActive, Zuvio

F1::
ControlSend,,/p hi, ahk_id %polid1%
Send {enter}
return


This results in me saying 'hi' in the party chat window. which means that {enter} was received by the active window. I'm kind of stumped here, because my knowledge of AHK is not that great to go to the next step, that is sending the {enter} key to my background window. I'm searching the AHK forums etc. but it feels like this particular topic has not been adressed all that much. (for stubborn games at least)

[Freddie]

Good. Okay, next step, can you take out the line that sends enter, and substitute a new line that sends {enter} using the SendPlay method? I don't know the exact syntax. This new version might work in the background.

[zuvio]

I've tried the following with and without SetKeyDelay. It did not send the {enter}.


WinGet, polid1, ID, Zuvio

#IfWinActive, Zuvio

F1::
ControlSend,,/p hi, ahk_id %polid1%
SetKeyDelay, 10, 10, Play
SendPlay {enter}
return


I tried the following code to see if SendPlay send anything at all. With the SetKeyDelay I neatly saw '/p hi' get typed into the chat input bar, but the {enter} was not received.


WinGet, polid1, ID, Zuvio

#IfWinActive, Zuvio

F1::
SetKeyDelay, 10, 10, Play
SendPlay /p hi{enter}
return

For what it's worth: SendInput {enter} and SendEvent {enter}did send the enter press to ffxi, with or without setkeydelay.

[Freddie]

Could you try increasing the delay to 200, 200 just for testing purposes?

[zuvio]

I tried a SetKeyDelay of 0, 1, 20 ,200 and 2000 ms, but it wont send the {enter} to FFXI :(

[Freddie]

Okay, in that case, I think the next step would be to try sending {enter} directly to child windows and controls inside the game window. AutoHotkey has a built-in utility called Window Spy that helps you identify the appropriate control. You can also use a freeware program called Winspector that will show you which controls inside the game window receive keystroke messages when they are typed normally. Once you've got an idea which control should receive the keystroke, you can try sending with commands like ControlSend, ControlSetFocus, etc.

This is a lot more complicated than what you've done so far. I don't know if you want to get this involved but I can't think of anything else to try.

[zuvio]

I will try and see if I can write the appropiate code. It never hurts to try. Your program already enables me to play FFXI 6 times on 2 PC's using the <sendwin> method with time delays. It works solid so far and the <wait> commands actually do not have the impact on gameplay you expect them to have. FFXi is not a 'fast' game with many commands, so when a command send to a clone to cast a black mage spell takes place 1 or 2 seconds later than expected, it really has little impact in overall gameplay. I am now succesfully running 6 accounts of FFXi, two on my main PC with one window completely pimped out graphics-wise and a small window and my second PC runs 4 tiled accounts with mediocre graphics and it all works very nicely and solid! So getting direct input to work would just be a bonus, since I'm already more than content with your program as it is now. :D

[Basilikos]

Freddie,

First, thanks for the great utility. Technically, it does what I need it to do in order to 5 Box WoW effectively. I'm just getting into that, by the way. I am still in the process of making sure I can do what I want before I buy the other machines.

Second, I have a couple of feature requests / suggestions. The first, and probably the easier to implement, is to allow for an "includes" file in addition to the hotkey files. Something like <include nameoffilehere> in the hotkey file you load so that you could sub in and out smaller sets of definitions at will. The second, and I believe you said it's in the works, is to allow HotKeyNet to communicate to the window in question that the user is holding a key down as opposed to the keydown, keyup messages sent now.

Third, more thanks. You deserve it.

[Freddie]

First, thanks for the great utility. Technically, it does what I need it to do in order to 5 Box WoW effectively. I'm just getting into that, by the way. I am still in the process of making sure I can do what I want before I buy the other machines.
Thanks for the thanks. :) It's comments like this that keep me going. Good luck with the quintet.


Second, I have a couple of feature requests / suggestions. The first, and probably the easier to implement, is to allow for an "includes" file in addition to the hotkey files. Something like <include nameoffilehere> in the hotkey file you load so that you could sub in and out smaller sets of definitions at will.
That sounds like a good idea but my priority is to add features that enable people to do things that they cannot currently do with the program. Right now, for example, it's impossible to use the program for movement keys in most games. I think I should add features for things like that before I work on things that add convenience but no new abilities. Include files would be a convenience but people can accomplish the same thing now (more awkwardly) by making multiple full copies of a file and changing each one. It probably seems like this feature would take only a few minutes to add (and indeed, if HKN was a quick-and-dirty program for my own use it would probably take about 5 minutes to add this) but since HKN is a published program this new feature would need error messages, it would need documentation, it would need to do something graceful when the include doesn't exist, etc... it woudl probably take hours to do it right.

However pretty soon I need to rewrite the file-loading stuff completely so HKN will check the syntax of the file and give the user helpful advice if something is wrong. Right now the program does no error-checking at all, and in fact you can feed any file whatsoever into HKN and it will try to execute it ... this is not good. :) When I rewrite that stuff I'll keep this idea in mind and try to build it in.. maybe i can add it pretty much "for free" by making the file-reading stuff recursive.


The second, and I believe you said it's in the works, is to allow HotKeyNet to communicate to the window in question that the user is holding a key down as opposed to the keydown, keyup messages sent now.
Yep. The first step in this direction will be the option to define different actions when you press a hotkey and when you release the same hotkey. This will allow people to send a "keydown" when they press a key and a "keyup" when they release it. This will enable movement in many games. After I see people's reactions to that, maybe I'll add more stuff along these lines. Maybe I'll have to add a true "send repeated keystrokes" capability, I don't know. I had hoped to put the press/release stuff in the next build but there may not be time since the current build is about to expire and I'll have to post a new build within the next few days. But it's coming soon.


Third, more thanks. You deserve it.
You're very welcome. :)

[Freddie]

Build 59 can now be downloaded from the website. It contains more changes than any previous build. New things include:

— All hotkey functions have been rewritten. The new code has a lot of advantages over the old code, but because it's new it probably contains some bugs and will need to be fine-tuned.

— The program now gives you feedback about your hotkey actions, making it easier to write hotkey files.

— The appearance of the main panel changed.

— Four new low-level commands have been added for sending to background windows and child windows including controls:

. . . . . . TargetWindow
. . . . . . TargetChild
. . . . . . SetSendMode
. . . . . . SetFocus

— Names of some commands changed.

— The name of the loaded hotkey file is now displayed.

— Many other changes.

[Freddie]

Build 60 is up. Like the previous build, this is a big one with significant new features and changes.

One downside: the syntax for hotkey files changed. You'll have to rewrite your definitions slightly. Sorry about that. When you load your old hotkey files, the program will tell you what needs to be changed.

http://www.hotkeynet.com/p/download.html

[lockpwn]

I have had a hard time with hotkeynet it was very complicated and i couldent figure it out so i just gave up and removed it from my computer.

[Freddie]

I'm sorry to hear that. I've tried very hard to make the program easy to use. Can you tell me specifically what was so hard? Maybe I can make it easier.

[Basilikos]

Freddie,

I'm really excited about the movement key stuff in the latest build. What I'd like to know, though, is exactly how HotKeyNet determines what is and is not a valid hot key. Specifically, are you the one that determines what combinations are not allowed or is there some underlying dependency in the operating system that prevents you from allowing more key combinations? What I'm looking to do is add a numpad key in front of combinations that are allowed now.

Is that possible?

Thanks.

[Basilikos]

I'm sorry to hear that. I've tried very hard to make the program easy to use. Can you tell me specifically what was so hard? Maybe I can make it easier.
I have had a hard time with hotkeynet it was very complicated and i couldent figure it out so i just gave up and removed it from my computer.

Freddie,

I'm doing my best not to violate forum policies while still getting my point across here. This guy can't actually play WoW since he uses trial accounts only and doesn't appear to be above the age of 13 or so. Check his post history if you're curious for details. There isn't anything wrong with HotKeyNet's usability and even if there were, this guy wouldn't be the one to tell you.

Moderators: I think I'm in line here. If I'm not, let me know.

[Freddie]

What you are suggesting could be done. But I think it comes at a price. Let's say you define the numpad-enter key as the first key in the combination enter-ctrl-F3. In effect you're using it as a modifer key like ctrl, shift, and alt.

Now let's see what happens when you press the numpad-enter key. Normally it generates a "return" keycode. But now HKN has to consider the possibility that you are pressing it only as a modifer for your hotkey combo. In which case you don't want it to generate an "returnr" key code. So surely HKN should swallow the "return" keycode -- in other words, it should disable the key from its normal function.

This is why the "real" modifiers (shift, alt, ctrl) don't generate anything by themselves. If they did, they wouldn't be suitable as modifiers. It seems to me that if you want to use other keys as modifiers, certainly that could be done, but like the real modifiers, they have to be disabled from generating anything by themselves.

This wouldn't be hard to implement. But I chose not to (so far at least) because I thought most people would find it confusing. I imagined them writing a single hotkey defintion with some "normal" key as a modifier. Then they load the definition, and suddenly they key is disabled except when it's used to trigger that hotkey. Then they get mad at the program and remove it from their hard disk. :)

[Freddie]

I appreciate your last post a lot. What that guy said was on my mind when I just answered you. :)

[Katharsis]

*roar*

http://feathermoon.us/images/katharsis/hkey61.jpg

[Basilikos]

This is why the "real" modifiers (shift, alt, ctrl) don't generate anything by themselves. If they did, they wouldn't be suitable as modifiers. It seems to me that if you want to use other keys as modifiers, certainly that could be done, but like the real modifiers, they have to be disabled from generating anything by themselves.
Now I see the deal here. I should have been able to guess that (what with being a software engineer and all), but I don't mess around with anything that touches OS-level material that much. Anyhow, perhaps I'll explain what I'm trying to do and you may or may not have a better suggestion for me.

Basically, I just started multiboxing WoW. I am running my main character off of one machine and built two others that each run two WoW instances. What I wanted the numpad keys for was to help direct input to the slave characters. Really, I just need the number keys for what I wanted. I am already using a Nostromo N52 and have three main hotbars plus the pet and shapeshift / aura / whatever bar attached to it. I simply needed a way to let HotKeyNet know how to direct the commands from the N52 to the proper window on the proper machine.

On an off note, I'm really pleased that we now have the option for movement keys. Before, I had to write a little 120 line program to output all the various combinations of modifiers and keys that I wanted to direct with HotKeyNet. Your slight modifications to the command format with the last build didn't really bother me since I just had to tweak a single line of code and rerun the program.

Anyhow, I'll look for another solution in the mean time since there are a few issues to be considered here. Perhaps adding in the option to turn the numpad into a set of modifier keys?

Thanks.

[Freddie]

Edit: I wrote a lot of stuff while I thought about your problem ... maybe you should skip to the last message in this series and read that first.

I'm not sure I understand the problem but no matter what it is exactly, you apparently need a lot of different

<Hotkey A B C D>

combinations. And you think you don't have enough. Is that the problem in a nutshell?

Let me stop and count for a minute. HKN distinguishes left and right modifiers in a hotkey definition. So these are two different hotkeys:

<Hotkey Lshift X>
<Hotkey Rshift X>

That means for each modifer "slot" in the hotkey trigger, you have three possibilities (left, right, or none), for a total of 3^4 = 81 combinations of modifiers. Those combinations apply to each key on the keyboard. If there are 90 usable keys on the keyboard -- i haven't counted -- that's 90 x 81 possible hotkeys = at least 7200 possible HKN hotkeys.

So my question is, are you really running out?

[Freddie]

Basilikos, two more things. With HKN you can send commands from any keyboard, not just the server's keyboard. So if you're willing to use two keyboards, that's 7200 x 2 combinations. Etc.

Second thing, I just got an idea. I'm not sure this would help but Let me bounce it off you. I could add a feature so you could define 4 gig's of hotkeys by triggering them with a number:

<Command 862>
<sendpc local>
<sendwin Wow>
...etc

The way you'd input the number into HKN is by first triggering a special hotkey function that tells HKN to start interpreting keyboard input as digits in that number. So, for example, the Nostromo would invoke command 826 by typing:

Ctrl F3 // you defined this to invoke the hotkey that listens for a command number
8
6
2
escape // tells HKN that the number is complete ... HKN now executes command 862

This would give you 4 gigs of hotkeys but I'm not sure it helps anything because I don't know how you input 4 gig's of possibilities into the NOstromo to begin with. But I"m not grasping the context of the problem.

[Freddie]

Come to think of it, HKN already has a feature almost exactly like that. You can define commands that are triggered by strings of text like this:

<Command MyCustomCommandText>
<sendpc local>
<sendwin blahblah>
etc.

Right now when you want to invoke that command, you input the text to HKN with HKN's command line window, but I could very quickly add a new hot key function that allows the Nostromo to type the command text directly into HKN the way I described for numbers in the last post.

This would give you (aside from memory constraints) an infinite number of hotkeys, because the length of the command text is unlimited.

(If you wanted to use this on a large scale I'd probably have to rerwrite the code that interprets the command names and make it much faster. Right now it just does a bunch of strcmp's, and I've never tested it with more than 3 or 4 commands.)

But again, I'm wondering, how do you input all these thousands of commands into the Nostromo to begin with? The more I think about this, the more it seems like the bottleneck is there, not in HKN, but maybe I'm missing the whole point.

[Freddie]

Maybe I just figured out what you mean. Do you want to tap a key that means "The next hotkey should be sent to Client X." then you tap something that invokes a hotkey whose definition, by itself, doesn't designate any particular window. When the hotkey executes, it takes its target from the target that was picked by the previous key tap.

Is that it? If so, I dont think this is a matter of modifiers. I think it has to do with adding some kind of state variable to HKN so it remembers from one hotkey to the next what the desired target is. Right now HKN loses its memory completely between hotkeys. :)

it would work like this:

<Hotkey F1> // F1 will direct commands to WoW 1
<sendpc local>
<SetDefaultTarget Wow1>

<Hotkey F2> // F2 will direct commands to Wow 2
<sendpc local>
<SetDefaultTarget Wow2>

<Hotkey F3> // output will go to whatever was picked with previous hotkeys
<SendWin %DefaultTarget%>
<text blah blah blah>

Is that what you were thinkikng of?

[Basilikos]

Freddie,

Like I said, there is a very strong likelihood that I have just not thought through all the possibilities. I'm currently taking advantage of the fact that HKN does differentiate between left and right keys to send commands to all four slaves. I do have keyboards attached to the two slave machines, so that is definitely useful. I will need to check on whether or not the Nostromo software supports left and right differentiation on all modifier keys (I'm certain it does on SHIFTs, but I don't recall the others).

To answer your more specific questions, right now I have 1-0, -, and = bound to three hotbars inside my main WoW client. The first bar is accessed simply by the stated keys. The second is accessed through the named keys and the left shift button. The third is accessed through the left alt key and the stated buttons. The pet and shapeshift bars are accessed through either CTRL and 1-0 or CTRL+ALT+1-0. What I was looking for was an easy way to specify a specific client that should receive the command from the N52.

I'll look over things again and see what I can get going. The real issue is going to be overlapping combinations of CTRL or ALT+CTRL (or similar combinations) and whether or not the Nostromo software recognizes left vs. right everything.

Thanks for all the attention you give the community here.

[Freddie]

Did you read my last msg? I think all the earlier ones probably missed the point.

[Freddie]

*roar*

http://feathermoon.us/images/katharsis/hkey61.jpg

Bah, blue is so boring. Red ftw!!!

http://hotkeynet.com/art/errors.gif

[Draku]

I just did the dailies (about 2 hours) using Hotkeynet and using movement keys for formation and for initiaiting flying (ie going up at start), works perfectly.....

[Freddie]

Woot! Thanks for letting me know.

One sad thing though -- I just rewrote Key, KeyDown, and Keyup. So they all have to be tested again. ;(

You already know this but for other folks, I did it to make them 100% consistent with each other. Now they have the same syntax and call the same code.

[Basilikos]

Maybe I just figured out what you mean. Do you want to tap a key that means "The next hotkey should be sent to Client X." then you tap something that invokes a hotkey whose definition, by itself, doesn't designate any particular window. When the hotkey executes, it takes its target from the target that was picked by the previous key tap.

Is that it? If so, I dont think this is a matter of modifiers. I think it has to do with adding some kind of state variable to HKN so it remembers from one hotkey to the next what the desired target is. Right now HKN loses its memory completely between hotkeys. :)
That is pretty much the behavior I was looking for, but I think this solution presents problems to me that I'd rather avoid.

I'd like whatever key(s) I use for these "per-client" modifiers to be just like any other modifier. I don't want any state to change based on what key I just pressed. If I decide split-second not to take whatever action I was considering, I don't want to have to worry about what client I just selected; I'd really rather just take my finger off the key and have things be as they were.

Like I said, I'm still looking into how the Nostromo handles left or right modifier keys.

[Freddie]

That makes sense. Also it occured to me after I posted that idea that when you assign any unmodified key to be a hotkey, like I suggested for the state change hotkeys, they get just as "disabled" for other purposes as they would if you made them modifiers.

I had a few more ideas but I wonder, could you describe with some concete examples what keys you would like to press, ideally, for this? And would you press them on the Nostromo or the PC? How many keys do you want to press at a time? etc?

[Basilikos]

...could you describe with some concete examples what keys you would like to press, ideally, for this? And would you press them on the Nostromo or the PC? How many keys do you want to press at a time? etc?Certainly. For starters, I was only going to use the numpad keys to direct where the other key presses would go (NUMPAD0 would be a general broadcast to all slave clients, NUMPAD2 to the second client, and like that up through NUMPAD5 to the fifth client). The rest of the key presses were going to occur on the Nostromo and these key presses already used some SHIFT, CTRL, and ALT modifiers (and sometimes, ALT+CTRL and other combinations). And before I forget, there were a few other keys (ESC, B, SPACE, etc) that I had on the Nostromo as well besides the 1-0 (and -,= depending on the bar we're talking about).

The idea was that I could keep all the functionality I had on my main AND use the same controls on the slaves (either individually or as a group). Right now, I'm using the RSHIFT as a general broadcast modifier. If memory serves, the Nostromo software doesn't differentiation between the left and right CTRL and ALT keys (well, it might for ALT). If it did, I could just alter the script I use to output all of the hotkey definitions and load them into HKN.

And on another note, the Nostromo and HKN get along pretty well. HKN is able to see and capture the appropriate events nicely.

In general, I don't think I'll press more than 4 keys at a time (the client modifier, two regular modifiers, and some other key be it numerical or alphabetical).

Did I get everything?

Thanks.

[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.

[Freddie]

I decided to do this in two steps so we can do some testing in between. That will make it easier to catch bugs.

The first step, which I just finished, was to rewrite the keyboard hook. That's in build 64 which is on the website now. It doesn't do anything new, but it's designed in a way that will make it possible to add the new feature. If you could test it a little bit, I'd appreciate it, because there's a lot of new code inside.

The second step will be to add the new feature. I think that will be easier than step one.

[Freddie]

Here's the documention page for the new modifiers. We can look at this page now as a specification for the code that I'm about to write. if you think the design should be changed, and you can tell me now before I start writing, that would be a big help.

http://www.hotkeynet.com/ref/usekeyasmodifier.html

By the way this new keyword isn't necessary for technical reasons. I could just simply let people use any keys in any order in hotkey triggers. But they can disable keys by doing that, so I thought it's a good idea to require this keyword to alert them to the consequences.

It's a tradeoff: a little more typing for everybody to reduce confusion for certain users.

[Basilikos]

if you think the design should be changed, and you can tell me now before I start writing, that would be a big help.

No, not at all. That is quite a bit simpler than I had imagined it being.


By the way this new keyword isn't necessary for technical reasons. I could just simply let people use any keys in any order in hotkey triggers. But they can disable keys by doing that, so I thought it's a good idea to require this keyword to alert them to the consequences. It's a tradeoff: a little more typing for everybody to reduce confusion for certain users.

This sounds perfectly reasonable.

I've really enjoyed using HKN and am looking forward to this feature. Thanks so much.

[Freddie]

Okay, it's done. Build 65 is on the website now with enough key combinations for a bazillion hotkeys. Here's an example of the new "anything-goes" hotkey triggers:

http://www.hotkeynet.com/art/custom-modifiers.gif

I used the feature for about 20 minutes after I finished it today, and I really like it. You can make "chords" (like guitar chords) to send commands. I'm glad you talked me into this. It's very cool.

I was careful to implement this in a way that lets you have as many as 16 keys in a trigger. But when I finished the work and tried it, I had a major doh! moment. Because the keyboard (or device driver or something in the chain) won't send more than five pressed keys at a time to the system. If you press a sixth key, nothing is received. So the maximum number of keys in a trigger (on my test PC, anyway) is five.

I wrote this pretty fast and didn't test very carefully so there are probably some bugs. Let me know if you find any and I'll fix them right away.

Thanks for the kind words in your last message, and thanks again for suggesting this. I'm glad it's in the program now.

[Freddie]

Build 66 is on the website now. It contains a new function called ThirdPartyCommandLine ('http://www.hotkeynet.com/ref/thirdpartycommandline.html') which works exactly like the existing CommandLine ('http://www.hotkeynet.com/ref/commandline.html') function except for one crucial detail.

With the old function, you enter your command in HotkeyNet's pop-up window. With the new one, you enter your command in a text-entry field that belongs to whatever program you're using.

Why was this added? Because the old function doesn't work in full screen mode. The new one does.

[Basilikos]

Build 66 is on the website now. It contains a new function called ThirdPartyCommandLine ('http://www.hotkeynet.com/ref/thirdpartycommandline.html') which works exactly like the existing CommandLine ('http://www.hotkeynet.com/ref/commandline.html') function except for one crucial detail.

With the old function, you enter your command in HotkeyNet's pop-up window. With the new one, you enter your command in a text-entry field that belongs to whatever program you're using.

Why was this added? Because the old function doesn't work in full screen mode. The new one does.

That is Hawt. I was just wondering about how to do this.

[Freddie]

I just rewrote the tutorial for commands. I think it's much clearer now:

http://www.hotkeynet.com/p/doc7.html

[Draku]

:) :) :) :) New Build seems really stable......so....I am going to push my luck.

We are back to the 'state' question. What I would like to do is define a bank of keys (F5-F8) to have different meanings based on a toggle that I can dynamically change. This would allow me to configure my attack commands depending on the situation. eg Grinding/Boss Fight/PVP

I would prefer not to use key modifiers for this (purely because it would be more effort to press/mash the keys!). In my mind, I imagine something like a sticky modifier key similar to how <caps locks> works in a normal environment. ie you press it once, and all keys are sent as if you were pressing <SHIFT> and the key press it again and they revert to their unshifted state

So I would like to have F5 send F5 to the clients unless the caps lock had been pressed, in which case it would send something else (perhaps <CTRL> <LWIN> F5). HKN would need a feedback mechanism to indicate the state of the toggle, (conveniently most keyboards have an indication for caps lock)! Would also be nice to have an indication on the HOTKEY tray icon. I guess it would be good to consider having the ability to define what key is the toggle, but then the feedback mechanism would be less good (ie just within HKN)

Just to be clear, I would need to be able to specifiy that a key behaves differently depending on the state of a toggle

Another similar implementation is the Logica G15 keyboard's ability to provide 3 different configs of one bank of of keys, switched by a dedicated 3 buttons (M1, M2, M3). This is more of a 'radio button' metaphor though than a toggle, ie one of the 3 must be down, and this determines which code the G15 sends.

What do you reckon?

Product is the dogs bollocks (as us brits say!)

[Freddie]

:) :) :) :) New Build seems really stable......
That's good to hear.


HKN would need a feedback mechanism to indicate the state of the toggle
Yeah I think that's essential. Unfortunately the tray icon is already used to show whether hotkeys are on, so we seem to be limited to the three keys whose toggle state is shown by LEDs on the keyboard.

Of those three keys, Num Lock already does what you want without my having to do anything, provided you assign your hotkeys to the shiftable numpad keys instead of function keys. There are eleven of them, so you'd get 22 hotkeys in all.


Product is the dogs bollocks (as us brits say!)
I hope that's a good thing :)

[Draku]

Could the Tray Icon have more than 2 states? eg-:

Could we make the tray icon show more than 2 states?

Grey - HKN disabled/Non-Grey -HKN enabled and Icon looking like a T - Toggle on/ Not looking like a T toggle off - or something like this?

I thought about the num lock situation, however it doesn't really help me. The thing is the number pad (with numlock off) duplicates keys that I already use (home, delete, up arrow etc)

The Dogs bollocks is indeed good

[Freddie]

I should mention, in case anybody doesn't know, that HotkeyNet lets you use all your keyboards and they can do different things. So F1 on the first keyboard does one thing, but F1 on another keyboard does something else. Every keyboard can control all the PCs because all PCs are equal with HKN -- there are no primaries and no secondaries. I myself use three keyboards when I multibox, and each keyboard controls all five of my toons.

I'm mentioning this because almost everyone who emails me for help is using HKN as if it's a keybroadcaster, with one machine that sends keypresses to others. You can use it that way if you want, but that's a fraction of what it can do. It's a program that makes all pc's capable of controlling all pc's.


Could we make the tray icon show more than 2 states?

If we do this (a) at best it's going to be limited to one key and (b) the icon would become much harder to interpret with a glance.

In comparison, the LEDs (a) work with three keys and (b) don't reduce the clarity of the icon at all. So LEDs seem better to me. It's true that the icon would allow you to choose any toggle key you like, whereas the LEDs restrict you to three pre-selected ones, but this limitation seems unimportant to me because the LED keys include the only key on the keyboard that is perfect for this purpose -- the NumLock key. It's perfect because it has no other purpose except to be a toggle key, so you lose nothing when you select it for this purpose. The Scroll Lock key is nearly as good because it no longer does anything in most programs. The Caps Lock key is probably the worst key on the board for this purpose because it changes the built-in function of every printing key, but two out of three isn't bad.

Also, LEDs have the enormous advantage of allowing you to use combinations of your three toggle states (e.g. both NumLock and ScrollLock down at the same time vs. only one of them down). This would give you seven toggle states in all vs. just two toggle states with the icon.

[Draku]

Regarding the multi-kb thing.......that is interesting........I need to give that some more thought...

So, having caps lock, num lock and scroll lock plus combinations would be perfect.

Is there a way that to stop Numlock making the numpad keys the direction keycodes? or is that a hardware thing. In other words, I would like to have numlock change the meaning of F1-F5 and leave the numpad keys unchanged. If this is impossible, which the more I think about it the more unlikely it is to be possible, then it will still be fine if I can use capslock and scroll lock.

Would this functionality be hard to implement?

By the way, a solution to feedback could be adding extra tray icons I know I have a wireless keyboard where the software does this for capslock and numlock

[Freddie]

Is there a way that to stop Numlock making the numpad keys the direction keycodes? or is that a hardware thing. In other words, I would like to have numlock change the meaning of F1-F5 and leave the numpad keys unchanged.
There's no difficulty here. The only hard thing is figuring out a syntax that allows users to request this behavior in a way that makes it simple to understand.


Would this functionality be hard to implement?

No. But it would take a few hours, mostly for documentation.


By the way, a solution to feedback could be adding extra tray icons I know I have a wireless keyboard where the software does this for capslock and numlock
I'll think about it.

[Draku]

No. But it would take a few hours, mostly for documentation.

Can I help? If you come up with the design, I would be happy to draft something and then you can use or not

[Freddie]

Well first we have to figure out the syntax. Actually first I have to decide if I want to do it. It's a good idea but maybe something else should get done first.

But if you want to make suggestions about the syntax, fire away. I was thinking:

<Hotkey X> always gets triggered by X regardless of toggle state.
<Hotkey NLUP X> gets triggered by X only if num lock is up
<Hotkey NLDN X> gets triggered by X only if num lock is down

when you add in the new modifiers, this could get pretty verbose:

<Hotkey NLDN SLUP numpad_end LSHIFT LALT F3>

It will have to be illegal (generate an error) if somebody tries to define a toggle key as a modifier and also use it as a toggle.

The syntax for numpad keys is going to have to be a special case since they each have two names, depending on whether num lock is up or down. I think the least-confusing thing will be to require people to define two hotkeys for those keys if they want both NL states to do the same thing for those keys.

[Draku]

If we constrain it to just caps and scroll, it seems to be a nice and logical extension to current functionality

Syntax - I would go for

<Hotkey X> always gets triggered by X regardless of toggle state.
<Hotkey NUMLOCK(UP) X> gets triggered by X only if num lock is up
<Hotkey NUMLOCK(DOWN) X> gets triggered by X only if num lock is down

[Draku]

The syntax for numpad keys is going to have to be a special case since they each have two names, depending on whether num lock is up or down. I think the least-confusing thing will be to require people to define two hotkeys for those keys if they want both NL states to do the same thing for those keys.

This sounds fine and easy to understand

[Draku]

<Hotkey NLDN SLUP numpad_end LSHIFT LALT F3>
<Hotkey NUMLOCK(DOWN) NUMPAD_END LSHIFT LATL F3>
verbose yes, but fairly logical I think

[Freddie]

HKN has about 30 keywords, and for every single one, the syntax is like this:

<Keyword Arg1 Arg2 Arg3>

Now you're suggesting that for three new keyword, they should have a different syntax like this:

Keyword ( Arg1 )

I think syntax should be consistent. This is very important. It makes the program easier to understand and use.

However. Let's consider switching all the functions over to your syntax. That would be consistent. It would look like this:

Hotkey ( NumLock ( down ) X )

I've actually thought many times that maybe I should do this. In fact, if I had written the program for myself, I would have done it this way from the beginning. It has the great advantage of allowing nested functions, as this example shows. Also it's familiar to programmers since it's C syntax. But I think it has the disadvantage of making the program even geekier and more frightening for the average person than it already is.

[Draku]

mmmh.....

I wasn't treating NUMLOCK as a keyword but as a key. or are all keys keywords?

I was adding () to indicate state....

When you proposed NLDN and SLDN was that intended to be new keywords? or were you abbreviating NUMLOCKDOWN and SHIFTLOCKDOWN?

I guess all I was doing was using existing keys and adding the brackets to separate the state. it seemed like a good idea so that if you need to refer to whether a key is down or not in the future you would have the syntax

[Draku]

Maybe we should also stop using up and down here...

I think On/Off is better

So how about

So <Hotkey NUMLOCK(ON) CTL F1>

[Freddie]

I don't think definitions matter here. The point is, everything in a hotkey file looks like this:

<something arg1 arg2 arg3>

And you're suggesting adding three things that look like this:

something ( arg1 )

You don't think that's inconsistent?


I guess all I was doing was using existing keys and adding the brackets to separate the state.
Yes but you're adding something that doesn't currently exist in HKN's syntax, and thereby creating an inconsistency.


it seemed like a good idea so that if you need to refer to whether a key is down or not in the future you would have the syntax
Yes, that's one of the advantages of your syntax. That's one of the reasons your syntax is used in industrial-strength programming languages like C and C++. But this doesn't change the fact that it's a different syntax from the one the program currently uses. The syntax must be consistent, so the only way I'd use your suggestion is if the syntax were switched over 100%. As I said in my last email, this would have advantages. But I think it also has the enormous disadvantage of appearing much more difficult to average people. That last consideration outweights all others, in my view.

[Freddie]

I think On/Off is better
Here's a good rule of thumb. When designing interfaces (whether it's a script language or the index of a book or the menu in a program), always pick the word that is most likely to pop into the user's mind.

Ttry it in an ordinary sentence.

"My cat jumped on the keyboard and pressed the key _____ by mistake."

Down or On? Which comes to mind?

[Freddie]

Hmm on second thought you're right about on/off. The key isn't down in this situation.

[Draku]

mmmh this stuff is not easy!

I think on/off is correct.......

I certainly would not want to change the whole syntax...it works well and is easy to use.

Problem (and I think you raised this before in this thread) is that we need to add a capability in the <Hotkey> definition to test a state before executing the hotkey commands. It is hard to be consistent when state checking is not really implemented elsewhere in HKN

The proposal is that the capslock on/off state is convenient because of the built in feedback mechanisms in the keyboard

I was associating the state with the key. This might not be useful. ie we could (although we probably dont want to) treat the capslock button completely separately from the capslock state.......this is probably not a helpful line of thought


Perhaps we go for

<Hotkey CTRL F1 CAPSLOCK=ON>

[Freddie]

I think on/off is correct.......
I agree with you. (I said so above, I changed my mind.)


Problem (and I think you raised this before in this thread) is that we need to add a capability in the <Hotkey> definition to test a state before executing the hotkey commands. It is hard to be consistent when state checking is not really implemented elsewhere in HKN
What we need to do is write code for two different states. One way to handle that is with testing. But that's not the only way. Let me illustrate with an example. When we added hotkeys that fire on key release, the syntax could have been designed like this:


<Hotkey F1>
IF release
do something
IF press
do something else

But here's how I designed it:


<HotkeyUp F1>
do something

<Hotkey F1>
do something else

The two chunks of code do exactly the same thing, but one tests explicitly and the other doesn't. I chose the second option because I think it's less intimidating to average users. We can do a similar thing with toggles.


Perhaps we go for
<Hotkey CTRL F1 CAPSLOCK=ON>

Once again, this is inconsistent with the existing syntax. The exisitng syntax doesn't use the equality symbol, and it has no concept of assignment or equality.

[Draku]

I understand your points (I think)

I would be happy.....if not delighted.....if I could say <HOTKEY CAPSLOCKON CTRL F1>..........and......to be honest I can appreciate that if we take the existing HKN language, then this is really very clear and easy...... (In other words I think I was wrong!)

I sort of think I have got carried away with this, but at least I now understand where you are coming from

[Freddie]

Cool. Your ideas were good ones -- I wouldn't say they were wrong. They just don't fit our constraint here. Our constraint is that we need a solution that matches the existing script language. (Or else come up with something that is so much easier for average users that it would be worth converting the whole scrpt language to the new syntax.)


I sort of think I have got carried away with this...

I don't think so, not at all. We only looked at three ideas! You want to get carried, away, let's try to list 25 ideas. :)

[Draku]

I am now worrying about whether we should be more verbose and precise......ie have CAPSLOCKLIGHTON, NUMLOCKLIGHTON,SCROLLLOCKIGHTON

as opposed to CAPSLOCKON, NUMLOCKON, SCROLLOCKON

.......Probably a bit too obscure/arcane/subtle (whichever you choose) too worry about

Anyway....any thoughts on where this is on your product roadmap???????

[Freddie]

Well somebody's gotta wory about it because every detail no matter how small has to be decided. With names, it's nice to do three things at once: (1) make them long enough so users know their meaning without having to look them up but (2) make them as short as possible and (3) make them consistent with similar names that are already in the program.

As far as (3) goes, the program already uses the names NumLock, ScrollLock, and CapsLock.

If we follow those three guidelines I think the choice makes itself.


Anyway....any thoughts on where this is on your product roadmap???????
I don't know. There are some other things I should probably do first, like add another background send mode and tweak all the background send modes so they work better (e.g. handle mod states properly). Then I should probably add "game guides" to the website that show people how to get started fast with various games. However it's much more fun to add new features to the program. :)

[Draku]

As far as (3) goes, the program already uses the names NumLock, ScrollLock, and CapsLock.

If we follow those three guidelines I think the choice makes itself.


I was indeed to obscure!!!

I am worried that if we use CAPSLOCKON we are implying a too firm connection with the key CAPSLOCK

I can't remember if I said this before, but ...

We could (although we probably don't want to) treat the CAPSLOCK light state completely separately from the CAPSLOCK key (I think)

In other words define the F1 key to switch the state on and off and define the CAPSLOCK key to do something different

As I said.....obscure...but I thought I would seed the thought

[Freddie]

I didn't realize you wanted to assign the LEDs to different keys. Interesting idea. It never occurred to me.

My initial reaction is, I'm not sure but I think the LEDs are controlled by the keyboard driver. If so, it's probably way too much work. If you assign an LED to a new key, then the old key loses it indicator, and that would tend to confuse people.

[Draku]

I didnt want to have this functionality.......happy the leds stay.......sorry I have added confusion........

During our discussions, it occurred to me that the LEDS were actually something different to the keys.........and I wanted to consider this as part of our design discussions

Don't even consider doing it.........

THis is a bit like your 'cat jumped' thing....I like to think what is 'really' going on

[Freddie]

I think it's good to suggest a lot of ideas. Brainstorming, we call it.

[Draku]

I don't mean to chase, did you decide if you were going to implement this or not?

[Freddie]

I decided to wait until I decide how to implement "execute this hotkey only if such-and-such a window is in the foreground" because that may require if statements, and the syntax for the two things should probably be similar.

[Draku]

I decided to wait until I decide how to implement "execute this hotkey only if such-and-such a window is in the foreground" because that may require if statements, and the syntax for the two things should probably be similar.

Have you implemented this? I noticed a release and this function
'SendFocusWin /Sends keystrokes to the window that has the focus. '

[Freddie]

Sorry, no, it hasn't been implemented yet. SendFocusWin is unrelated to waiting for a window. It sends keystrokes to whichever window happens to be active.

Are you asking about the led/toggle stuff because you have an urgent need for it? Or just curious?

[Wilbur]

Innerspace is a Developers platform for DirectX games.

(Think botting..)

http://www.lavishsoft.com

[Draku]

Sorry, no, it hasn't been implemented yet.
Are you asking about the led/toggle stuff because you have an urgent need for it? Or just curious?

Well I want to change my config, and for me, having two or three different 'set ups' switchable by a key for the F1-F4 bank of keys would make a big difference. If the capslock/scrolllock function is available then it would make my life easier. If not, I am going to have to do something more dramatic.

Is it urgent? well everytime I wipe to a boss, I think about it .....but it isn't stopping me playing and it certainly isn't rl life or death. :)

[Draku]

Innerspace is a Developers platform for DirectX games.

(Think botting..)

http://www.lavishsoft.com

This is pretty random isn't it? or are you suggesting HKN or my request is moving toward botting?

[Freddie]

I see. I'll get to it as soon as I can. There are several things I want to do first including improved security and making shift/alt/ctrl work better when sending to background windows.

[Freddie]

This is pretty random isn't it? or are you suggesting HKN or my request is moving toward botting?

I'm guessing it was posted in the wrong thread by accident.

[Draku]

I see. I'll get to it as soon as I can. There are several things I want to do first including improved security and making shift/alt/ctrl work better when sending to background windows.

Ok...that would be great........ :)

Let me know if I can do anything to help.

I must admit, this mod seems a very natural extension to the existing key functionality

[Freddie]

Second, I have a couple of feature requests / suggestions. The first, and probably the easier to implement, is to allow for an "includes" file in addition to the hotkey files. Something like <include nameoffilehere> in the hotkey file you load so that you could sub in and out smaller sets of definitions at will.
It took me a while but this suggestion has now been implemented in build 83. For more info, click here ('http://hotkeynet.com/ref/includefile.html').

[Basilikos]

Second, I have a couple of feature requests / suggestions. The first, and probably the easier to implement, is to allow for an "includes" file in addition to the hotkey files. Something like <include nameoffilehere> in the hotkey file you load so that you could sub in and out smaller sets of definitions at will.
It took me a while but this suggestion has now been implemented in build 83. For more info, click here ('http://hotkeynet.com/ref/includefile.html').

ZOMG I was mentioned on the Include File page. Thanks, Freddie. All in all, as someone who codes for a living, this was the most natural choice of broadcasting programs to use and quite honestly, I have yet to see a feature of another program that makes me question HKN.

[Freddie]

I really appreciate that. Thank you sir.

If you think of anything else you want in the program, let me know.

[kandore]

Hi Freddie - thanks for such a great program. I had to take a break from boxing but I'm back into it! I ran into a problem today though, and I'm hoping it's just sucky coding on my end. I'm pretty sure my macros used to work, so maybe there was an upgrade in language and I'm still using some old code...
I looked at the reference section of your site but KeyDown and KeyUp look like they function the same way they always have.

Here is some code that I pass to my secondary computer in order to execute attacks.

<hotkey F6>
<sendpc ip address removed for posting>
<sendwin EQ2>
<KeyDown LAlt><wait 100><Text 4><wait 100><KeyUp LAlt>
<wait 1000>
<KeyDown LAlt><wait 100><Text 1><wait 100><KeyUp LAlt>
<wait 1000>
<KeyDown LAlt><wait 100><Text 2><wait 100><KeyUp LAlt>

My other computer seems to receive the correct code, but it only holds down Alt for the first attack, after that it just presses 1 and 2 without the alt. All of my singular macros that just have one key held down, button, and then key up work fine, but once I add in another one it stops seeing the keydown/up. This is what my other computer says it receives.

<SendWin EQ2> completed: Window found. Target set to 0x280134 "EQ2"
<KeyDown LAlt> completed
<Wait 100> completed: 100 milliseconds
<Text 4> completed
<Wait 100> completed: 100 milliseconds
<KeyUp LAlt> completed
<Wait 1000> completed: 1000 milliseconds
<KeyDown LAlt> completed
<Wait 100> completed: 100 milliseconds
<Text 1> completed
<Wait 100> completed: 100 milliseconds
<KeyUp LAlt> completed
<Wait 1000> completed: 1000 milliseconds
<KeyDown LAlt> completed
<Wait 100> completed: 100 milliseconds
<Text 2> completed
<Wait 100> completed: 100 milliseconds
<KeyUp LAlt> completed

Thanks for your help! (I also tried increasing the delay from 1000ms to 2000ms but that didn't work either)

[Freddie]

This is an interesting mystery. I don't know what's wrong, but let's find out. Here's a question and a suggestion:

1. If you press that hotkey once, EQ2 sees Alt-4, 1, 2. If you immediately press that hotkey again, what does EQ2 see the second time?

2. Go to the settings panel and uncheck "Attach theads for SendInput." Please let me know if that helps. If not, we can try some other things.

Edit: Here's a second question. If this is the only hotkey with this problem, what does Alt-4 do in EQ2?

[kandore]

Ok, tested all of this out. If I hit the hotkey twice in succession it continues to go off the same way, using Alt the first time and then just hitting 1 & 2 after that. I tried taking off "Attach threads for SendInput" and also "Clear Modifiers Before Executing Hotkey" but neither of them did anything.

To answer your second question, I also have this problem with Ctrl, and it happens regardless of using Alt/LAlt/RAlt and Ctrl/LCtrl/RCtrl. The Hotbars in eq2 are set up to first use 1 through =, then Alt 1 through Alt =, and lastly Ctrl 1 through Ctrl =. So I have 3 hotbars of 12 actions that I can work with before I have to get into moving the mouse to click the buttons. For me Alt 4 casts a reactive heal.

I can definitely work around this if we can't figure it out, I just found it odd. At least I can still use Ctrl and Alt buttons, just not with any other ones, lol.

[Freddie]

Thanks for testing. We'll figure it out if we keep investigating. I'm puzzled too. But with software there's always some simple mechanical explanation, even if it's not obvious at the beginning.

Please can you clarify your answer to one of my questions. You said Alt-4 casts reactive heal. I don't play EQ2 so I don't know what that does exactly. I'm trying to rule out the possibility that the in-game action is affecting this. Does reactive heal change focus? Does it cause a window to appear? If you haven't already, could you try the same exact thing except with different in-game actions (as different as possible from reactive heal) and see if the same problem occurs, and let me know?

Moving on, two new things.

(1) Question. When you pressed the hotkey twice in a row, did the foreground window change in between for any reason?

(2) Suggestion. Try changing the hotkey so it types LAlt only once like this:


<hotkey F6>
<SendPC #.#.#.#>
<SendWin EQ2>
<KeyDown LAlt>
<Wait 100>
<Text 4>
<wait 100>
<Text 1>
<wait 100>
<Text 2>
<wait 100>
<KeyUp LAlt>

[kandore]

Ah ha, it doesn't like the nested <keydown alt> action <keyup alt> wait <keydown alt> action <keyup alt> etc. It worked with your code that had it hold down Alt, perform all the actions, and then let it up at the end. I'm going to test now if it will let me use that method, but also switch to Ctrl since some of my other macros use alt hotkeys followed by ctrl ones.

To answer your other questions, my second computer that is receiving the commands only has EQ2 in the foreground, so my focus never changes. Healing in eq2 is similar to other games (I think) in that it doesn't open any windows or change my target. I have the same problem whether I start with my heal or not. Basically I have my second toon target my main toon and cast through him at all times. If it's a heal or beneficial spell it automatically goes on my main toon, and if it's an attack it goes on my main toon's target due to the implied target set up. My window never flickers or anything like that.

Okay...off to test more once I get my toons to a safe spot.

[kandore]

I played with this a bit more and it looks like using <KeyDown LAlt> all of my alt actions and then <KeyUp LAlt> works, but only if it's the only command being executed by that hotkey. I tested this out and the following code works fine

<hotkey F6>
<sendpc ip removed for post>
<sendwin EQ2>
<KeyDown LAlt>
<wait 100>
<Text 8>
<wait 1000>
<Text 9>
<wait 100>
<KeyUp LAlt>

But this code does not (I added in <Text 1> which just puts me into autoattack mode. I tried other actions and they had the same result)

<hotkey F6>
<sendpc ip removed for post>
<sendwin EQ2>
<Text 1>
<wait 100>
<KeyDown LAlt>
<wait 100>
<Text 8>
<wait 1000>
<Text 9>
<wait 100>
<KeyUp LAlt>

[Freddie]

Thanks. When you say the second hotkey in your previous post didn't work, do you mean that EQ2 received 1, 8, 9 instead of 1, LAlt-8, LAlt-9?

[kandore]

Yup, that's what I mean. It looked like it received the correct keystrokes according to Hotkeynet on my other computer, but in game only the numbers were pressed without LAlt.

[Freddie]

I loaded that second definition into HotkeyNet 117 and tried it with Dark Age of Camelot, and it worked properly, so this may have something to do with EQ2. I should have asked you earlier -- which build of HotkeyNet are you using?

Let's try something else. Could you test this definition? It has a SendWin before every KeyDown:


<Hotkey F6>
<SendPC local>
<SendWin EQ2>
<KeyDown LAlt>
<Wait 100>
<Text 1>
<wait 100>
<KeyUp LAlt>
<Wait 1000>
<SendWin EQ2>
<KeyDown LAlt>
<Wait 100>
<Text 8>
<Wait 100>
<KeyUp LAlt>
<Wait 1000>
<SendWin EQ2>
<KeyDown LAlt>
<Wait 100>
<Text 9>
<Wait 100>
<KeyUp LAlt>
<Wait 100>

[Schizo]

Hi I have a question that I have not seen the answer for yet. maybe it allready has it in here and if it does I apologize. Is there any special configuration to tell it where to load wow from. I run two copies of wow on the same system. the folders are different names. Called wow1 and wow2 respectfully. where in the text file would you place this. Forgive my newness to it.

PS I really so far like the program for its simplicity. It seems like it will be able to do what i need without the bloat of some. Thanks for the work you have put into it.

[Warchamp7]

I download Hotketnet and 2 hours later theres a new release lol

Great work with this program Freddie :D

[Freddie]

Is there any special configuration to tell it where to load wow from. I run two copies of wow on the same system. the folders are different names. Called wow1 and wow2 respectfully. where in the text file would you place this. Forgive my newness to it.
There are a lot of ways to do this. I just wrote a script to do it a pretty easy way and noticed a bug. Let me fix the bug and upload a new build (to annoy Warchamp! :) ) and then I'll answer this.


PS I really so far like the program for its simplicity. It seems like it will be able to do what i need without the bloat of some. Thanks for the work you have put into it.
Glad to hear it! Thanks. :) And you're welcome.

[Freddie]

I download Hotketnet and 2 hours later theres a new release lol

Great work with this program Freddie :D
Watch out for that new build unless you have a high tolerance for pain -- it's "experimental" meaning it has a lot of new code in it that might set your PC on fire.

Thanks for the kind words. :)

[Warchamp7]

I download Hotketnet and 2 hours later theres a new release lol

Great work with this program Freddie :D
Watch out for that new build unless you have a high tolerance for pain -- it's "experimental" meaning it has a lot of new code in it that might set your PC on fire.

Thanks for the kind words. :)

Pfft, my computer already locked itself up a few times tonight. Though after installing a more recent video driver I seem to be okay.

I've pretty much got everything set up right now to test tommorow. Have some spell macros and a PiP set up.

[Nostromos]

Freddie is purty much awesome...

[eqjoe]

Freddie is purty much awesome...

/agree

HKN rocks.