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
Printable View
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
You can't yet, but it's on the list of things to add.
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
Download HotkeyNet 48 here
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?
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.
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.
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.
Woohoo, thank you. I definitely appreciate all of the work you're putting into it. I look forward to the future builds :)
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.
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.
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?
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.
Try this page.Quote:
Originally Posted by Rimmel',index.php?page=Thread&postID=32136#post321 36]...this softwares' Server to Client connection set up was so simple that I really look forward to using this more in the future. [/quote]
Thanks! That's just about the biggest compliment I can imagine for a piece of software.
[quote='Rimmel
And this one.
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 :)Quote:
Originally Posted by 'Freddie',index.php?page=Thread&postID=32131#post3 2131
50 is up. :)
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.
Unfortunately no luck for me when running with 2 instances on 1 PC. Are you running between 2 PCs or a single?Quote:
Originally Posted by 'kandore',index.php?page=Thread&postID=32128#post3 2128
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?).
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.
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.Quote:
Originally Posted by 'kandore',index.php?page=Thread&postID=32373#post3 2373
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.
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.Quote:
Originally Posted by 'Freddie',index.php?page=Thread&postID=32375#post3 2375
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.
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. :)
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.
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.
I'm downloading updates to EQ2 so I can try sending to it in the background. :)
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 :)
> Thanks for checking into eq2 personally...we're a mess
:D
I'm looking at MouseClick in EQ2 now.
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.
Code:<HotKey F1>
<SendPC 192.168.1.102>
<SendWin EverQuest>
<MouseClick window nomove>
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.
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?
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.Quote:
Originally Posted by 'kandore',index.php?page=Thread&postID=32830#post3 2830
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.)
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.
Thanks. What's the CPU specs in that machine? Brand, cores, GHz?
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.
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!
Why don't you post it when you get home and i'll take a look at it.
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?
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:
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.PHP Code:
<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>
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 :(
PHP Code:
<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>
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
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.Quote:
Originally Posted by 'mana333',index.php?page=Thread&postID=36995#post3 6995
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.)