DAoC dual-boxing

[Freddie]

Wow, Matt, thanks for the incredibly kind words. Like I said earlier you were a tremendous help. And it was fun working together with you on the program -- a nice break from the usual solitary programming routine. College comes first but maybe we can do it again.

[Nisch]

Well I gave your program a whirl. I kept running into an issue where if I set a hotkey to send to the background window, it wouldn't allow my normal keystrokes to go to the foreground window. I actually would have to write a hotkey for the foreground window as well even though that's the active window. Sounds like its a keyboard hook.....is that the case?

Anyhow, I did see a few missed keystrokes, but overall, it's a pretty nifty program. If you ever make it open source, I'd like to play around with it. I may give it another shot here soon, but I went ahead and bought a 5th computer this week for my goals.

You asked what advantage hardware has over your program. First get the banstick. I'm not running a single piece of software on my setup. Another would be the missed keystrokes. In my case, I'm playing 4 PBAOE casters and my main, which is a bard. and I need the spells to go off every time or I get into a bad situation. Lastly, I have a full keyboard at my disposal for my 4 casters, and a standalone for my main. That gives me about 150 usable keys to play around with. That would be one hell of a hotkey file ;(

But, when it comes down to price.......ease of setup........and price......oh and Price........HotKeyNet is something I'd recommend to anyone. Nice product.:thumbsup:

[Freddie]

Well I gave your program a whirl. I kept running into an issue where if I set a hotkey to send to the background window, it wouldn't allow my normal keystrokes to go to the foreground window.

Thanks a lot for trying it and giving me feedback. I'm really glad you told me about this problem. I'll have to fix it. I'm surprised, though, because I never heard of it before. Could you send me the hotkey definition? I'd like to find the cause of this and fix it.

The opposite problem has been in the program for a long time, namely, if you're using SendWinM, and if you type keystrokes into the foreground window while a macro executes in the background, the keystrokes get copied to both windows. I just added SendWinMF to address that. It succeeds in blocking the copying but at the expense of occasionally blocking some of the macro output to the background. The next thing I'm going to try to improve it further is buffering of typed keystrokes like AutoHotKey has.

Sounds like its a keyboard hook.....is that the case?

I'm not sure what you mean. Yes, the program installs a keyboard hook but except for one narrow exception, the hook has nothing to do with whether keystrokes get through to a window. The hook just looks to see if you've pressed a hotkey. The exception is that the hook blocks the key that triggers one of its own hotkeys.

Anyhow, I did see a few missed keystrokes...

That's obviously a dealbreaker. If you could send me the hotkey definition, I'd really appreciate it. On my three pc's, this happens with the new SendWinMF syntax, but not with the older syntax of SendWinM-plus-background_setfocus, which is clumsy, and which I'd like to phase out.

...but overall, it's a pretty nifty program.

Thanks, I appreciate it.

If you ever make it open source, I'd like to play around with it.

Well, that's unlikely, but you never know. But I will probably add a bunch of low-level functions that expose a lot of Windows API stuff directly to the user.

You asked what advantage hardware has over your program. First get the banstick. I'm not running a single piece of software on my setup. Another would be the missed keystrokes. In my case, I'm playing 4 PBAOE casters and my main, which is a bard. and I need the spells to go off every time or I get into a bad situation. Lastly, I have a full keyboard at my disposal for my 4 casters, and a standalone for my main. That gives me about 150 usable keys to play around with. That would be one hell of a hotkey file ;(

I see. Thanks for explaining. The first advantage I can't compete with. The second I'm pretty sure I can. The third disadvantage -- well, is it really a disadvantage? You can certainly have 150 hotkeys defined, if you want them.

But, when it comes down to price.......ease of setup........and price......oh and Price........HotKeyNet is something I'd recommend to anyone. Nice product.:thumbsup:

Hehe. Thanks again.

[Nisch]

Well I gave your program a whirl. I kept running into an issue where if I set a hotkey to send to the background window, it wouldn't allow my normal keystrokes to go to the foreground window.

Thanks a lot for trying it and giving me feedback. I'm really glad you told me about this problem. I'll have to fix it. I'm surprised, though, because I never heard of it before. Could you send me the hotkey definition? I'd like to find the cause of this and fix it.

The opposite problem has been in the program for a long time, namely, if you're using SendWinM, and if you type keystrokes into the foreground window while a macro executes in the background, the keystrokes get copied to both windows. I just added SendWinMF to address that. It succeeds in blocking the copying but at the expense of occasionally blocking some of the macro output to the background. The next thing I'm going to try to improve it further is buffering of typed keystrokes like AutoHotKey has.

Sounds like its a keyboard hook.....is that the case?

I'm not sure what you mean. Yes, the program installs a keyboard hook but except for one narrow exception, the hook has nothing to do with whether keystrokes get through to a window. The hook just looks to see if you've pressed a hotkey. The exception is that the hook blocks the key that triggers one of its own hotkeys.

Anyhow, I did see a few missed keystrokes...

That's obviously a dealbreaker. If you could send me the hotkey definition, I'd really appreciate it. On my three pc's, this happens with the new SendWinMF syntax, but not with the older syntax of SendWinM-plus-background_setfocus, which is clumsy, and which I'd like to phase out.

...but overall, it's a pretty nifty program.

Thanks, I appreciate it.

If you ever make it open source, I'd like to play around with it.

Well, that's unlikely, but you never know. But I will probably add a bunch of low-level functions that expose a lot of Windows API stuff directly to the user.

You asked what advantage hardware has over your program. First get the banstick. I'm not running a single piece of software on my setup. Another would be the missed keystrokes. In my case, I'm playing 4 PBAOE casters and my main, which is a bard. and I need the spells to go off every time or I get into a bad situation. Lastly, I have a full keyboard at my disposal for my 4 casters, and a standalone for my main. That gives me about 150 usable keys to play around with. That would be one hell of a hotkey file ;(

I see. Thanks for explaining. The first advantage I can't compete with. The second I'm pretty sure I can. The third disadvantage -- well, is it really a disadvantage? You can certainly have 150 hotkeys defined, if you want them.

But, when it comes down to price.......ease of setup........and price......oh and Price........HotKeyNet is something I'd recommend to anyone. Nice product.:thumbsup:

Hehe. Thanks again.

The hotkey file is the example you put in this post. I just tested one hotkey for one function for testing. However, I notice you mentioned that the program does block the keys that are used as hotkeys. So this means that if I don't have a hotkey defied for the foreground window, it won't send that to the game in the foreground. I set my hotkey to "3" instead of F3, which is where I have my spells bound. Since I didn't have it set to send it to the foreground too, then that explains why it didnt' work. That's why I asked if it was a keyboard hook, becasuse it could be writted to intercept and essentially discard keystrokes, which it seems like it's doing.

I also noticed that you said the background_setfocus is old.......I didn't try the new way yet with the SendWinMF.

I'll give it another try and let you know what I find.

[Freddie]

I set my hotkey to "3" instead of F3, which is where I have my spells bound. Since I didn't have it set to send it to the foreground too, then that explains why it didnt' work. That's why I asked if it was a keyboard hook, becasuse it could be writted to intercept and essentially discard keystrokes, which it seems like it's doing.

Right, exactly. Since the program is a hotkey program, not a key broadcasting program, it has to offer the user the option of either passing that particular key through or not passing it through. I chose to make the first option the default since I figured that is what most people will expect from a hotkey program. But like you say, the other option is easy enough to arrange. It's just an extra two lines in the definition:

<hotkey 3>
<sendwin NameOfForegroundWindow>
3

I also noticed that you said the background_setfocus is old.......I didn't try the new way yet with the SendWinMF. I'll give it another try and let you know what I find.

Great. In that case I'm going to post a new build 51 later today with an improved <SetBackFocusDelay> which is necessary to tune SendWinMF. The new version of the command will take two arguments so you can fine-tune both the delay before and the delay after the send. If that doesn't work for you, then I still have the new buffering stuff up my sleeve.

[PyrostasisTDK]

Heya freddie!

Just curious, havent used your program before, are there any guides or walkthroughs up aimed at daoc? Id love to tinker with it.

[Freddie]

I also noticed that you said the background_setfocus is old.......I didn't try the new way yet with the SendWinMF. I'll give it another try and let you know what I find.

I just changed that stuff again in build 51 which is now on the site. I tested it in DAOC on two different PC's and didn't notice any missed keystrokes. Definitions can be a little simpler now:

<HotKey F3> 
    <SendPC Local> 
        <SendWinMF Uber1> 
            3 
        <SendWinMF Uber2> 
            3

However, when you try this, you may find that keystrokes don't always reach the background window. Or, conversely, you may find that if you type keystrokes into the foreground window while a macro executes in the background, your typed keystrokes go to both windows by mistake. If these things happen, you need to adjust the length of an internal delay with a new command, SetFocusDelay.

For example, if you need to make the delay longer, you would add a line to the definition like this:

<HotKey F3> 
    <SendPC Local>
        <SetFocusDelay 0 50>
        <SendWinMF Uber1> 
            3 
        <SendWinMF Uber2> 
            3

[Freddie]

[quote='PyrostasisTDK',index.php?page=Thread&postID =32520#post32520]Just curious, havent used your program before, are there any guides or walkthroughs up aimed at daoc? Id love to tinker with it.[/quote]
Howdy Pyrostasis. Not exactly but all the examples in the instructions on the website were written for DAOC because that's the game I was playing while I wrote them. The instructions [url='http://www.hotkeynet.com/p/doc.html']are here[/url].

[PyrostasisTDK]

Another question... is it possible, with out breaking the eula, to run more than 2 clients per machine?

Thats really cramping my setup =(

[Freddie]

I've been told by a friend who spent a few hundred hours looking at DAOC in a debugger that each instance of DAOC creates a mutex that other instances look for before they run. Assuming that he's right -- and I have no reason to doubt him, he's a very good programmer -- I can't think of any way that you could run more than two instances without violating the EULA. But maybe there's a way that isn't occurring to me.