when it doesn't open the game window, the code gets stuck at -> GamestepDisplay("Waiting for Game to start...") I need it to recognize that and return to another function which would be -> inqueue:
loop
{
GamestepDisplay("Waiting for Game to start...")
WinActivate, League of Legends ahk_exe LeagueClientUx.exe
sleep 250
HumanClickL(470, 360) ;click Reconnect button (even if not present)
WinActivate, League of Legends (TM) Client ahk_exe League of Legends.exe
sleep 250
if QueueCheck()=1
{
goto, inqueue
}
if QueueCheck()=2
{
goto, startqueue
}
CoordMode, Mouse, Screen
mousemove, A_ScreenWidth/2, A_ScreenHeight/2
click, Right
CoordMode, Mouse, Relative
PixelSearch, ci, di, 137, 0, 137, 0, 0xceae63, 5, Fast RGB
if ErrorLevel=0
{
WinActivate, League of Legends (TM) Client ahk_exe League of Legends.exe
SleepRandom(150)
goto, ingame
}
if ErrorLevel=1
{
SleepRandom(4000)
}
}
}
Else
{
Loop
{
if QueueCheck()=1
{
goto, inqueue
}
if QueueCheck()=2
{
goto, startqueue
}
}
}
she asks me
Related
This does not work, The Else block always triggers as soon as I hold down Xbutton2
XButton2::
If GetKeyState("LButton", "P")
{
Tooltip, LButton down
}
Else
{
Tooltip, LButton Not down
}
Below is another attempt I made sadly, the same thing as above happens.
XButton2::
GetKeyState, state, LButton
if (state = "D")
{
Tooltip, LButton down
}
else
{
Tooltip, LButton Not down
}
I am trying to make an AutoHotKey script that will spam the left mouse button whenever I am holding down on the mouse, but when I release it, it stops spamming left mouse button. I have started, but it isn't working the way I want it to. I am just getting two clicks and then it stops, even when I keep holding down the mouse button. Here is my code:
while (true) {
GetKeyState, OutVar, LButton
while (OutVar = "D") {
Send {lbutton}
GetKeyState, OutVar, LButton
}
}
And this is what I am using to test the mouse clicks.
Using Send to change the state of the button interferes with GetKeyState. You can solve this by using the P mode in GetKeyState, which retrieves the physical (real) state of the key.
#InstallMouseHook
Loop {
BtnIsDown := GetKeyState("LButton", "P")
While (BtnIsDown) {
Send {LButton}
BtnIsDown := GetKeyState("LButton", "P")
}
}
Alternatively, if you don't need to send the button up event, you can just use this:
Loop {
BtnIsDown := GetKeyState("LButton")
While (BtnIsDown) {
Send {LButton Down}
BtnIsDown := GetKeyState("LButton")
}
}
Simply,
Loop {
if GetKeyState("LButton")
Send {LButton Down}
else
Break
}
return
fly := True
Start()
{
Global fly
fly := True
While (fly == True)
{
Send, {Shift down}{W down}
Sleep, 10
}
}
End()
{
Global fly
fly := False
Send, {Shift up}{W up}
}
MButton::
Send, {K}
Start()
+XButton2::
Send, {K}
End()
Return
I don't know why, but everytime i stop the program it prints a double "k" at the final and i have no clue why is this happening, could someone point me where is the error? thank you very much!! ^v^
You're missing Returns to stop code execution.
Every hotkey label is to be ended with a Return so it doesn't bleed through to something unwanted (in your case, to the next hotkey label).
Your auto-execute section is also bleeding through, but in this instance it doesn't matter, since the code-execution encounters just functions before being stopped by a hotkey label.
Also, using SendInput is recommended over just normal Send.
And wrapping K in { } does nothing for you, and it could even result in undesired behavior in special cases (read the documentation for this).
Wrapping a character in { } is only to be done for escaping characters with special meaning in a send command, such as + (shift) or ! (Alt) (also read the documentation for a full explanation on this).
Here's an example of adding those missing Returns to your script:
fly := True
return
Start()
{
Global fly
fly := True
While (fly == True)
{
SendInput, {Shift down}{W down}
Sleep, 10
}
}
End()
{
Global fly
fly := False
SendInput, {Shift up}{W up}
}
MButton::
SendInput, K
Start()
Return
+XButton2::
SendInput, K
End()
Return
I'm making a simple 2d pong game. I finished everything now the only problem I have is that the GUI exit or restart button clicks are being recorded when it should not be recorded. Lets say both players fingers are on the screen and they move them so one players finger is 25 units from the button on the x axis and the others -25. These 2 finger touches somehow record as one finger touch in the middle of the screen where my exit button is and the app closes. I have 2 scripts for player controls one for Player 1 and other for player 2
var speed : float = 10;
function Update () {
if (Input.touchCount > 0)
{
var touchDeltaPos:Vector2 = Input.GetTouch(0).position;
if(Input.touchCount>1)
var touchDeltaPos2:Vector2 = Input.GetTouch(1).position;
if(touchDeltaPos.x<Screen.width/2)
{
if(touchDeltaPos.y > Screen.height/2)
{
rigidbody2D.velocity.y = 1*speed;
}
else rigidbody2D.velocity.y = -1*speed;
}
else if(touchDeltaPos2.x<Screen.width/2&&Input.touchCount>1)
{
if(touchDeltaPos2.y > Screen.height/2)
{
rigidbody2D.velocity.y = 1*speed;
}
else rigidbody2D.velocity.y = -1*speed;
}
}
if (Input.touchCount == 0)
rigidbody2D.velocity.y = 0;
rigidbody2D.velocity.x=0;
}
I don't know where your buttons are, but in any case how about making a buffer so it won't be touched by accident like
width = Screen.width/2 - 100
or minus 100 whichever works, the buffer is supposed to take in account the width and height of the finger as well
EDIT
When I say buffer, it means a temporary storage like a variable. So for the code you could do:
var buffer:int = 100;
(touchDeltaPos.x < Screen.width/2 - buffer)
Now why do this? Well, the buffer gives more room for the player's playing area from the exit button.
Here's my problem.
I wrote a little Volume Control Script to control my volume like windows do with it's Microsoft Keyboard's shortcut.
I have 3 functions. Two to controls volumes and the other one to control the Hold state of the key to continue rise or down my volume
Here's the code.
;//**************************************************
;// Volume Mouse Control
;//**************************************************
VolumeUp(p_numberToDecrease, p_holdToDecrease = true)
{
Send {Volume_Up %p_numberToDecrease%}
if(p_holdtoDecrease)
{
VolumeHoldTreatment("Up")
}
}
VolumeDown(p_numberToDecrease, p_holdToDecrease = true)
{
Send {Volume_Down %p_numberToDecrease%}
if(p_holdtoDecrease)
{
VolumeHoldTreatment("Down")
}
}
VolumeHoldTreatment(p_treatment)
{
Count := 0
Sleep 300
While GetKeyState(A_ThisHotkey,"P")
{
++Count
if(p_treatment == "Up")
{
Send {Volume_Up %Count%}
}
else
{
Send {Volume_Down %Count%}
}
Sleep 25
}
}
When I call the methods in the shortcuts like this ↓, they work correctly.
I can rise up and down my volume.
If I hold the key more then 300ms, the volume will continue rising/downing.
XButton1:: VolumeDown(1)
XButton2:: VolumeUp(1)
But When I add my mute shortcut ↓
XButton1 & XButton2:: Send {Volume_Mute}
XButton2 & XButton1:: Send {Volume_Mute}
The hold behavior don't act normaly. I need to press my Button1/2 two times to call the hold behavior. Why ?
Thanks for your help
The combinations
XButton1 & XButton2:: Send {Volume_Mute}
XButton2 & XButton1:: Send {Volume_Mute}
make XButton1 and XButton2 prefix keys. Prefix keys have a slightly different behaviour. They only fire upon release, which can't be avoided: For example, if you press XButton1, it is possible that you will press XButton2, causing the combination to be triggered. Only if you haven't pressed any additional button, XButton1:: will be triggered, and that on the other hand can't be determined before it was released.
To your VolumeHoldTreatment() function: In this case, a loop with GetKeyState() isn't necessary. A normal key will continue firing anyway when you hold it down. That's why some people are able to produce the word LOL with way too many O letters, with only three keystrokes.
Disregarding the mute function, something like this would do exactly the same:
XButton1::Send, {Volume_Down}
XButton2::Send, {Volume_Up}
Avoiding the use of a combination like XButton1 & XButton2 and therewith preventing the occurrence of prefix keys will save you a lot of trouble and can e.g. be accomplished like this:
XButton1::
if( GetKeyState("XButton2") ) {
Send, {Volume_Mute}
} else {
Send, {Volume_Down}
}
return
XButton2::
if( GetKeyState("XButton1") ) {
Send, {Volume_Mute}
} else {
Send, {Volume_Up}
}
return
This will work almost flawlessly: If you hold just one button, it will be triggered again and again, continuously sending Volume_Up or Volume_Down. As soon as you press both keys, two things will happen:
The key you pressed first will stop firing
The other key will send the {Volume_Mute}
Unfortunately, this comes with two downsides when muting: a) There will always be at least one Volume_Up or Volume_Down (even more when you take a really long time pressing the second button) sent before the {Volume_Mute} is sent. b) If you hold both keys for a long time, {Volume_Mute} will be sent over and over again; but this at least won't change the outcome.
Update:
The XButtons indeed show a strange behaviour, namely they don't keep firing when they are held down. Check out this code:
XButton1::
if( GetKeyState("XButton2", "P") ) {
SetTimer, FireVolumeUp, Off
Send, {Volume_Mute}
} else {
SetTimer, FireVolumeDown, 100
}
return
XButton1 Up::
SetTimer, FireVolumeDown, Off
return
XButton2::
if( GetKeyState("XButton1", "P") ) {
SetTimer, FireVolumeDown, Off
Send, {Volume_Mute}
} else {
SetTimer, FireVolumeUp, 100
}
return
XButton2 Up::
SetTimer, FireVolumeUp, Off
return
FireVolumeUp:
Send, {Volume_Up}
return
FireVolumeDown:
Send, {Volume_Down}
return
This has become more similar to your code, but it uses timers instead of loops, making the script able to execute other code in between timer runs. Also, I'm using XButtonN Up:: hotkeys, leading to more precision in terms of detecting the key release. The rest should be pretty self-explanatory. If you don't want the timers to wait 100 ms before their first run, add a GoSub, FireVolume... before each SetTimer.