[help][autoit][general programming]

[personinquestion]

I'm writing a WoW bot with autoit I intend to publicly release and I'm using the following for rotation:


Func _SetRotation ($Handle,$pBase, $RotNeeded)
Sleep(3000); for testing, make sure window we're focused on WoW
If (_GetRotation($Handle,$pBase)- $RotNeeded) < 0 Then
Do
Send("{D down}")
Until ((_GetRotation($Handle,$pBase)- $RotNeeded) > 0.0)
Send("{D up}")
EndIf
If (_GetRotation($Handle,$pBase)- $RotNeeded) > 0 Then
Do
Send("{A down}")
Until ((_GetRotation($Handle,$pBase)- $RotNeeded) < 0.0)
Send("{A up}")
EndIf
endFunc


The problem is that when I call it, nothing happens, however when I press the {enter} key (ingame chat key) I can clearly see that the {a} key is being pressed (via the string of "aaaaaaaaaaaaaaaaaaaa..." appearing on the screen)

Solution found, using controlsend instead of send
http://www.autoitscript.com/autoit3/...ontrolSend.htm
Also realized (via reply from this thread), should be
Send("{A down}")
Do
Until ((_GetRotation($Handle,$pBase)- $RotNeeded) < 0.0)
Send("{A up}")




I'm hoping to get a better way to send keys but this will be nice until finals are over.
Thanks to everyone who responded.

[Apoc]

Fairly sure this has been answered before. I may be wrong though, so feel free to discuss. (IIRC, this is just WoW weeding out the 'fake' input.)

[UnknOwned]

This is slightly off-topic so please delete if this is a violation of rules,
I'm writing a WoW bot with autoit I intend to publicly release and I'm using the following for rotation:


Func _SetRotation ($Handle,$pBase, $RotNeeded)
Sleep(3000); for testing, make sure window we're focused on WoW
If (_GetRotation($Handle,$pBase)- $RotNeeded) < 0 Then
Do
Send("{D down}")
Until ((_GetRotation($Handle,$pBase)- $RotNeeded) > 0.0)
Send("{D up}")
EndIf
If (_GetRotation($Handle,$pBase)- $RotNeeded) > 0 Then
Do
Send("{A down}")
Until ((_GetRotation($Handle,$pBase)- $RotNeeded) < 0.0)
Send("{A up}")
EndIf
endFunc


The problem is that when I call it, nothing happens, however when I press the {enter} key (ingame chat key) I can clearly see that the {a} key is being pressed (via the string of "aaaaaaaaaaaaaaaaaaaa..." appearing on the screen)

I've tried searching here and auto it forums but I really can't figure out why this is happening.

Again sorry this isn't memory related.

I would recommend you not to use "send" but controlsend so you can send it to wow no matter what window is active.
Also for general programming like this in autoIT i would highly recommend just asking on the AutoIT forums as its a very dedicated and a forum where you get a answer within minutes if you.

Regarding your question, if the A's get into the chat it seem like your bindings might be ****ed OR the A-Down was send before the WoWWindow was active and with that the hardware event that rotates the toon was not fired.

[Cypher]

I would recommend you not to use "send" but controlsend so you can send it to wow no matter what window is active.
Also for general programming like this in autoIT i would highly recommend just asking on the AutoIT forums as its a very dedicated and a forum where you get a answer within minutes if you.

Regarding your question, if the A's get into the chat it seem like your bindings might be ****ed OR the A-Down was send before the WoWWindow was active and with that the hardware event that rotates the toon was not fired.

Actually I'm pretty sure that WoW drops certain input regardless of whether it's the primary window. Either that or the Glider folks decided they would rather do a kernelmode API hook on GetForegroundWindow, GetActiveWindow, etc. than just use SendMessage.

I know for a fact though that in its primary message pump loop WoW checks whether it's the primary window before performing certain actions. It also checks in several other places for reasons I have not yet determined (didn't bother looking. prob not hard to figure out though.).

[lanman92]

Actually I'm pretty sure that WoW drops certain input regardless of whether it's the primary window. Either that or the Glider folks decided they would rather do a kernelmode API hook on GetForegroundWindow, GetActiveWindow, etc. than just use SendMessage.

I know for a fact though that in its primary message pump loop WoW checks whether it's the primary window before performing certain actions. It also checks in several other places for reasons I have not yet determined (didn't bother looking. prob not hard to figure out though.).

How did you find that out? They don't release info like that to the public do they? Or did you just debug it?

[Cypher]

How did you find that out? They don't release info like that to the public do they? Or did you just debug it?

Reverse engineering - Wikipedia, the free encyclopedia

[personinquestion]

Thanks for the feedback, I think Cypher is correct, and WoW detecting something funcky with my input, The window is definitely selected, I have more than 1 Sleep(3000) in my program outside this function for that purpose, the odd thing is that if i redesign the function like this,
Func _SetRotation ($Handle,$pBase, $RotNeeded)
Sleep(3000); for testing, make sure window we're focused on WoW
If (_GetRotation($Handle,$pBase)- $RotNeeded) < 0 Then
Do
Send("{D down}")
Sleep (10)
Send("{D up}")
Until ((_GetRotation($Handle,$pBase)- $RotNeeded) > 0.0)

EndIf
If (_GetRotation($Handle,$pBase)- $RotNeeded) > 0 Then
Do
Send("{A down}")
(Sleep 10)
Send("{A up}")
Until ((_GetRotation($Handle,$pBase)- $RotNeeded) < 0.0)
EndIf
endFunc

It works (but is odviously very choppy), I think I'll have to look into a new way to send input.

[ashleyww]

Try increasing the Sleep... it will allow it to move a little further... maybe try 30.

[kakamunsug]

I am pretty unsure of why WoW would block incoming focused (event_keybd) keystrokes if it accepts all the incoming unfocused (PostMessage).
But it could be the deal there, or you're randomly dropping the window handle at the wrong time. Could be that too, but please try using some other API as I don't even know what AutoIT uses at their "Send" function. But you should still work towards having a bot/whatever you're making - minimized and unfocused.

Look up either InjectMessage or PostMessage for a solution towards unfocused keystrokes, and either SendInput or Keybd_Event (a bit old API) to go towards the focused ones like Send in autoit.

Good luck, if you solve it, tell us your solution.

[Cypher]

I am pretty unsure of why WoW would block incoming focused (event_keybd) keystrokes if it accepts all the incoming unfocused (PostMessage).
But it could be the deal there, or you're randomly dropping the window handle at the wrong time. Could be that too, but please try using some other API as I don't even know what AutoIT uses at their "Send" function. But you should still work towards having a bot/whatever you're making - minimized and unfocused.

Look up either InjectMessage or PostMessage for a solution towards unfocused keystrokes, and either SendInput or Keybd_Event (a bit old API) to go towards the focused ones like Send in autoit.

Good luck, if you solve it, tell us your solution.

Actually I was in fact referring to unfocused. Again, it may just be the way Glider chose to do it, but it certainly does check focus for certain things.

[UnknOwned]

Actually I'm pretty sure that WoW drops certain input regardless of whether it's the primary window. Either that or the Glider folks decided they would rather do a kernelmode API hook on GetForegroundWindow, GetActiveWindow, etc. than just use SendMessage.

I know for a fact though that in its primary message pump loop WoW checks whether it's the primary window before performing certain actions. It also checks in several other places for reasons I have not yet determined (didn't bother looking. prob not hard to figure out though.).

Well my point was that if you send it to the window and not just "send" you can for example open messenger and chat with someone while the bot in the background is typing or using keys.

[amadmonk]

I've used PostMessage to trigger movements with just WM_KEYDOWN/WM_KEYUP stuff. There were a few things where I had to send a WM_ACTIVATE first (mouse input, specifically).

Interestingly, chat was the only things that DIDN'T work with the message posting method, and that was because there is like a 50ms delay in certain chat-related processing (for instance, after you press ENTER and before the chat line comes up, or after you finish entering chat text but before you can press ENTER again). If you avoid chat-related functions, just doing the correct sequence of PostMessage's works dandy. If you figure out and account for the weird delays, pretty much all text can be entered this way.

Not 100% sure that I haven't flagged myself by doing this, but I haven't been banned yet, and I tend to be very paranoid and use Spy++ and the like to make sure I mimic the actual sequence of events that occurs when a background window is activated (either via ALT-TAB or mouse). If you click the option to turn off sound in the background, for instance, and then send a WM_ACTIVATE, you'll hear the sound come on again.

Sadly, with the mouse capture stuff not playing nice for background windows, you can't really do anything that would involve more than a simple click in background windows, without being in-process.

[Cypher]

Or you'd have to do what Glider did and use a kernelmode solution. But in that scenario in-process is probably the 'better' alternative.

[zutto]

i had bit problems with this actually

biggest problem i had: repeatly sending the Down key -_- means :

send[key down]
do
until $crap = $crap1
send[key up]