[WAR] Software Broadcasting Script

[Sanctume]

Ok no problem. My laptop is laggy, probably due to having sli enabled.

Would HKN by itself work on my 2 computer setup though?

[Freddie]

Sure.

[Bachner]

Download HotkeyNet[/url]

Let me give you a simple script for testing. You need one hotkey to rename your Warhammer windows so HotkeyNet can tell them apart, a second hotkey to test whether you can send keystrokes, and a third hotkey to test whether movement keys work (they are more complicated than regular keystrokes).

 sample test code shown above

Unfortunately this test did not work for me. It failed first to rename the windows, even though it did not show an error message after attempting to do so. In fact, I'm unable to rename my WAR windows, even manually. Is there a permissions problem with vista?

I'm running 2 crossfired 3870's on vista 64.

Let me know if you would like me to try something different. I'd really like to see sendwinx working for my setup!

I used some random program to rename the window handles. Not sure if it does it appropriately for HKN because of the funkyness I'm experiencing. I went on to try your test script out and the opening of the bag/book worked perfectly for a few moments and now doesn't. I think the only thing I did was moved the window.

[Madman_Max]

I cant seem to get HotkeyNet to work reliably. The background window is dropping characters.

Frequently, the background window received the keystroke, but fails to execute it until I manually click on the background window or press another hotkey.

My script running with War1 the focus:

<Hotkey Ctrl R> // PRESS CTRL R TO RENAME WARHAMMER WINDOWS
<RenameWin Warhammer War1>
<RenameWin Warhammer War2>


<Hotkey F1> //OPEN BACKPACK ON BOTH CLIENTS
<SendWinx War1>
<Key B>
<SetBackgroundFocusDelays 15 50>
<TargetWin War2>
<SetPriority High>
<SendWinx War2>
<Key B>
<Restore>

<Hotkey F2> //OPEN HELP WINDOW ON BOTH CLIENTS
<SendWinx War1>
<Key H>
<SetBackgroundFocusDelays 15 50>
<TargetWin War2>
<SetPriority High>
<SendWinx War2>
<Key H>
<Restore>

If I alternate pressing F1 and F2, the background window will work correctly, open either the backpack or help window out of sequence, or do nothing at all.

[Bachner]

I'm now experiencing the same problems as Madman_Max is.

[Freddie]

Is there a permissions problem with vista?

Yes. The easiest thing to do is run it as admin.

I went on to try your test script out and the opening of the bag/book worked perfectly for a few moments and now doesn't. I think the only thing I did was moved the window.

That's the kind of thing I noticed too. I'm hoping we can figure out the exact pattern of events that makes it work / not work. If we can identify the exact conditions that make it work, maybe I can build that permanently into the program. (However I think the answer may be that it works perfectly when something gets cached by the OS or video card driver, and that might be impossible to accomplish on demand.)

[Freddie]

I cant seem to get HotkeyNet to work reliably. The background window is dropping characters.

I know it doesn't send keystrokes reliably to a Warhammer window that's in the background. What I'm asking people to do here is try to figure out the exact conditions under which it works until some second set of conditions stop it from working. If we can identify those two sets of conditions, then maybe I can modify the program so it keeps those conditions permanently established for itself.

Frequently, the background window received the keystroke, but fails to execute it until I manually click on the background window or press another hotkey.

That's a good observation. The next step is to distinguish whether it's really failing to execute or whether it's executing but the screen isn't getting redrawn. You can see the difference if your command makes the character do something visible in the game and you watch it from the other character's screen. (SendWinX turns off screen redraws for a background window while it sends keystrokes to the background.)

This may seem like a meaningless distinction but it's crucial for me know whether I have to worry about the keystroke getting received by the game or whether I have to improve the part of the code that forces a screen redraw.

<SetBackgroundFocusDelays 15 50>

"SetBackgroundFocusDelays" has no effect on SendWinX. Those delays only affect send modes with "F" in their names like SendwinMF and SendWinSF.

<SetPriority High>

Interesting idea. The way SendWinX works, it raises the background window to the foreground in the normal way, except it turns off screen redraw for a moment so there's no delay while the video card moves windows around. When a window gains the foreground, the operating system elevates its thread priority automatically, so the operating system is already doing this also.

If I alternate pressing F1 and F2, the background window will work correctly, open either the backpack or help window out of sequence, or do nothing at all.

Thanks for this observation. I'll look at this. (I suspect the out of order part may be due to delayed redraws. In other words, the keys may be doing their jobs immediately, but you don't see the results until later.)

[Madman_Max]

Frequently, the background window received the keystroke, but fails to execute it until I manually click on the background window or press another hotkey.

That's a good observation. The next step is to distinguish whether it's really failing to execute or whether it's executing but the screen isn't getting redrawn. You can see the difference if your command makes the character do something visible in the game and you watch it from the other character's screen. (SendWinX turns off screen redraws for a background window while it sends keystrokes to the background.)

This may seem like a meaningless distinction but it's crucial for me know whether I have to worry about the keystroke getting received by the game or whether I have to improve the part of the code that forces a screen redraw.

I forgot to mention this. Indeed the background window is sometimes recieving the keystrokes but failing to execute them. After being away from the computer for a few minutes I came back and clicked on a background window and the keystoke executed. It seems like they are being cached in a unreliable buffer associated with the background app.

I tested by sending the keystokes 5 and 6 which I had bound to verbal emotes on the ingame action bar, also sent Space for jumping. All cases seem to produce the same types of errors. Same thing happens when sending key to chat window in the background app.



Interesting idea. The way SendWinX works, it raises the background window to the foreground in the normal way, except it turns off screen redraw for a moment so there's no delay while the video card moves windows around. When a window gains the foreground, the operating system elevates its thread priority automatically, so the operating system is already doing this also.


I was trying to find a way to force a redraw, thinking perhaps that would yield different results. Didn't have any luck with the commands that I used. What are the proper commands to force a redraw, or is that possible at this time?

If I alternate pressing F1 and F2, the background window will work correctly, open either the backpack or help window out of sequence, or do nothing at all.

Thanks for this observation. I'll look at this. (I suspect the out of order part may be due to delayed redraws. In other words, the keys may be doing their jobs immediately, but you don't see the results until later.)


In my original example, it seemed to me that the "out of order" problem was due to key H being buffered, the subsequent key B takes its place in the buffer expelling H out of the buffer into the execution process. Perhaps this "buffer" is being shared by some other process, leading to unreliable results. Again, this doesnt seem to be just a redraw issue since "space" commands for jumping, and numbers bound to action bars produce the same errors.

All purely speculation from a layman's point of view :-)

[Freddie]

I was trying to find a way to force a redraw, thinking perhaps that would yield different results. Didn't have any luck with the commands that I used. What are the proper commands to force a redraw, or is that possible at this time?

Thanks for the additional info. I'll try to log into Warhammer over the weekend and look at the things you pointed out, especially the buffering. Layman or not, you might very well be right, and in any event I think the most important thing is simply to observe and describe accurately, and no technical knowledge is needed for that.

HotkeyNet has a built-in command called UpdateWin that asks a window to redraw itself. (The reason you couldn't find it is that I forgot to add a page about it to the documentation. I just did it a minute ago.)

You may find that UpdateWin always makes Warhammer redraw itself. However the window is free to disregard the request, and it's likely that UpdateWin won't work or won't work all the time. For testing purposes it might be better to really force the window to redraw itself. One way to do that is to resize it. You could do this with a hotkey that uses SetWinSize. I think a change of one pixel will probably be enough.

[Madman_Max]

I had some success with using SetWinPos to force a redraw of the background window. The following test script is functional if the keys arent pressed too rapidly.

<Hotkey Ctrl R> // PRESS CTRL R TO RENAME WARHAMMER WINDOWS
<RenameWin Warhammer War1>
<RenameWin Warhammer War2>


<Hotkey F1> //OPEN BACKPACK ON BOTH CLIENTS
<SendWinx War1>
<Key B>
<TargetWin War2>
<SetActiveWin>
<wait 30>
<SendWinx War2>
<Key B>
<TargetWin War2>
<SetWinPos 1000 0>
<wait 30>
<TargetWin War1>
<SetActiveWin>




<Hotkey F2> //OPEN HELP WINDOW ON BOTH CLIENTS
<SendWinx War1>
<Key H>

<TargetWin War2>
<SetActiveWin>
<wait 30>
<SendWinx War2>
<Key H>
<TargetWin War2>
<SetWinPos 1000 0>
<wait 30>
<TargetWin War1>
<SetActiveWin>