Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

Autohotkey and SAMP


  • Please log in to reply
3 replies to this topic
Dugz
  • Members
  • 2 posts
  • Last active: Jul 28 2013 11:35 PM
  • Joined: 27 Jul 2013

Well, I have this autohotkey script I wrote and it looks like this:

1::SendInput t/engine{enter}
2::SendInput t/lock{enter}

What I need to do is this: If I open the chat box manually in game (I press t) and then I randomly press the hotkeys (1 for example), I don't want them to send anything! If the chat box is on the screen - hotkeys should be void during that time; They only should work when the chat box is hidden/closed.
 
It is frustrating because when I'm typing something and I need to put a number, it sends the bind instead and all my text written before where the number is needed becomes gibberish.
 
Example:
"Hello, I'm Dugz and I'm t/engine"
 
I think I'm pretty clear on this one. Is there any way to achieve this? What kind of conditional would I need?
 
Thank you.



JadeDragon
  • Members
  • 935 posts
  • Last active: Jun 07 2014 07:40 AM
  • Joined: 18 Jan 2013

first of all, it's important to fully understand when a chat box can be opened and when it cannot. Generally a chat can be opened even during a fight sequence so you will need some way to determine your fight situation. That could be done easily by building a loop that constantly checks to see if the chatbox is open. All visual UI elements have some constant elements like a position on the screen a color somewhere in that element -- something about that element that doesn't change from run to run of the program. It could be something  as simple as a constant color at a fixed location on the screen or it could be a more complext visual image that you can capture and save and scan for periodically while your script is runninng. Once you can uniquely and reliably identify when a chat box is on the screen then you will also have to check to see if you are in or out of fight mode so you won't be sending fight sequence keys to the chat interface instead of the game's fight handler. A more drastic method might be to use the presence of the chat box itself to turn off any fight sequencing in your script.

 

Another way might be to have your fight sequencer turn off or prevent any chatboxes until the fight ends. Only you can decide which strategy would fit what you see in your mind as happening in your script.

 

It would seem to be to be most important first to be able to reliably identify when a chat box is actually present on the screen. Once you have that the battle is half won.


Never assume evil intent when simple ignorance will suffice. Ignorance is an eventually curable condition with the right education. Evil intent, however, is another matter entirely. Scripts are much like children. Simple to conceive. Difficult, expensive, and time-consuming to raise. Often do the opposite of what you expect them to. Require frequent  "correction". And once they leave home you can't control them anymore. But you love them anyway.


Dugz
  • Members
  • 2 posts
  • Last active: Jul 28 2013 11:35 PM
  • Joined: 27 Jul 2013

I'm a total newbie in autohotkey, I used it for the first time just 2 days ago. I actually understand what you mean, but it's quite impossible for me to script that yet. If you have SAMP experience, you might know how the chat box looks like (black, top left corner). I would appreciate an example on how to set this up. 

 

Thank you.



JadeDragon
  • Members
  • 935 posts
  • Last active: Jun 07 2014 07:40 AM
  • Joined: 18 Jan 2013

I don't play SA:MP so i can't help you there. But what i would do is to use a pixel grabber to find a constant color from the chat box that is in the same place every time. I believe I posted a script in the Scripts Section that can do that. but you will have to save the location and color so your script can check that location whenever you want to find out if the chat box is present. If it is then you can turn off your fight mode and deal with the chat box. That would be the simplest way. With games I play i try to make sure a fight is finished and i'm in a safe place where i won't be attacked when i use any in-game chat boxes. Most of the time I just ignore the chat box when i'm adventuring or fighting anyway. I'm not sure but you may be able to find that script here...

http://www.autohotke...253-jadedragon/

 

copy and save to your script directory and read the information and comments i've put in the file to learn how to use it.

 

Here is the script in case the link didn't go through...



This is a simple little routine from my toolkit that allows you to grab colors from your game screens in many games that allow pixel reads. It has a color preview gui embedded in the routine so you can see what the color looks like before you grab it, allows both on pixel and off pixel colors in case the color changes if you mouse over it and embeds a function that will verify the color with a best-2-out-of-3 trial read if the color varies or cycles as the game is running. It uses the RGB switch for the pixel grabber and verifier so the grab and the reads are compatible and it will put the grab result on the clipboard so it can be pasted into your own scripts if needed. It can be used for simply verifying colors at a given location on your screen, or helping you figure out exactly which colors and locations you need to program into your own scripts for your own custom pixel scans. I make no guarantees this will work for any given game or application since some games are more "difficult" to work with than others.

;--------------------------------------------------------------------
; JD's Color Scanner and verifier system
;--------------------------------------------------------------------
#NoEnv
#singleInstance, Force
#MaxThreadsPerHotkey, 3
SetBatchLines, -1
DetectHiddenWindows, On
CoordMode, Mouse, Screen
CoordMode, Pixel, Screen
CoordMode, Tooltip, Screen
SetTitleMatchMode, 2
SetKeyDelay, 30,50
SetMouseDelay 10
SendMode Event

;.................................
; Common to all modules
SplitPath, A_ScriptFullPath, ofname, ofdir, ofext, ofnamene, odrv
SetWorkingDir, %ofdir%
IniFile = %ofnamene%.ini
passback = Passback.ini ;<-- interprocess communication file

Blank =
centerx := (A_ScreenWidth // 2)
centery := (A_ScreenHeight // 2)

;------------------------------------------------
; loc/color grabber with timer display and preview window
; Use the middle mouse button to exit the routine
; Because some applications change the color of
; or highlight the the item the mouse is hovering
; over this this routine grabs two colors from 
; the selected location -- the color displayed 
; when the mouse is on the location and the color 
; that is displayed when the mouse is not on the 
; location. This method allows you to choose which
; color choice best works for you. The location and
; colors are copied to the clipboard as a comma-
; separated value so it can be pasted into a text
; file or directly into a variable in a script.
; -----------------------------------------------
+!g:: ;<-- tkGrabIt
tkGrabIt:
	KeyWait, b
	IniRead, GButton, %inifile%, Setup, GButton, MButton
	MouseGetPos, oposx, oposy ;<-- the off color position
	Sleep 200
	tkGrabItTimerFlag = 1
	gosub tkGrabItTimer
	Return
;................................................
tkGrabItTimer:
	Suspend, On
	MouseGetPos, mx, my ;<-- the on color position
	sleep 200
	pixelgetcolor, mouseoncolor, %mx%,%my%, Alt RGB ;<-- get the on color
	Sleep 200
	str = %mx%`,%my%`,%mouseoncolor%
	Tooltip, %str%`nUse the Mouse %GButton% to grab the loc and colors...,,,3

	; support for the color box
	gx := (mx + 20)
	If (gx > (A_Screenwidth - 50))
		gx := (mx - 100)
	gy := (my + 50)
	If (gy > (A_ScreenHeight - 50))
		gy := (my - 100)
	gmcolor := MouseOnColor
	gosub tkCreateColorGui

	If (GetKeyState(GButton, "P"))
	{	SoundBeep
		Tooltip, Release Mouse %GButton% to continue...,,,3	
		KeyWait, %GButton%	
		If (tkGrabItTimerFlag)	
		{	tkGrabItTimerFlag = 0
			MouseMove, %oposx%, %oposy%
			PixelGetColor, mouseoffcolor, %mx%,%my%, RGB ;<-- get the off color
			str = %str%`,%mouseoffcolor%`,`;OnPos-Color`, OffPos-Color in RGB Format
			Gui,9: Destroy
		}
		clipboard = %str%
		ClipWait
		tooltip,,,,3
		Suspend Off
		Return
	}
	suspend, off
	SetTimer, tkGrabItTimer, -100
	Return
;................................................
;gui for color picker
tkCreateColorGUI:
	;vgColor = 0xFFC0C0 ;<-- pale red
	;vgColor = 0xC0FFC0 ;<-- pale green
	;vgColor = 0xC0C0FF ;<-- pale blue
	;vgcolor = 0xFFFFC0 ;<-- pale yellow
	;vgcolor = 0xFFC0FF ;<-- pale violet
	;vgColor = 0xC0FFFF ;<-- pale teal
	vgColor = 0xFFC090 ;<-- flesh

	Gui,9: Destroy
	Gui,9: color, %vgColor%
	Gui,9: -Border
	Gui,9: Add, text, x8 y8 vcolor1txt, %gmcolor% RGB
	Gui,9: Add, Progress, E0x1 x7 y22 w76 h18 background0x000000 c%gmcolor% vcolor1Box, 100
	Gui,9: Show, x%gx% y%gy%
	Winset, AlwaysOnTop, On 
	Return

;------------------------------------------------
; pixel check routine based on the values returned
; by the tkGrabIt routine. Routine returns a 1 if match
; or 0 if no match on the color at the designated
; location. No checks are made for input validity.
; make sure the input is correct in all respects 
; before calling this routine.
; parameter tkGrabItStr format is x,y,oncolor,offcolor,[comment]
;------------------------------------------------

tkfnPixelCheck(tkGrabItstr)
{	If (tkGrabItstr = "None")
		Return 0
		
	; split the tkGrabIt string up into it's component parts
	stringsplit, tkGrabItary, tkGrabItstr, `,
	
	; grab the value of the current pixel color at the location
	; in question the same way the grab was made.
	; Best 2 out of 3 tries because the color could be varying
	sum = 0
	loop, 3
	{	pixelGetColor, thiscolor, %tkGrabItAry1%, %tkGrabItAry2%, alt, RGB
		sleep 200 ;<-- allow the color to stabilize
		; check the color in both forms because we don't always know
		; where the mouse is and if the color at that point is
		; highlighted or not.
		if ((thiscolor = %tkGrabItAry3%) || (thiscolor = %tkGrabItAry4%))
			sum += 1
	}
	Return, (sum > 1)
}

Esc::ExitApp



Never assume evil intent when simple ignorance will suffice. Ignorance is an eventually curable condition with the right education. Evil intent, however, is another matter entirely. Scripts are much like children. Simple to conceive. Difficult, expensive, and time-consuming to raise. Often do the opposite of what you expect them to. Require frequent  "correction". And once they leave home you can't control them anymore. But you love them anyway.