Help With Pixelsearch..

[Devilman]

Im trying to get pixel search to locate an item on screen, but one problem is that the item can be quite varied in its shade of colour, depending on conditions.

there is however, 4 seperate (and very different) colours all close together on the item.

What I want to do, is have pixelsearch look for the first colour with a fairly large tolerance, then when it finds something thats close, to search within a box of xx dimentions around that location for one of the other colours (and possibly a 3rd time for a different colour, to be sure)

My question is, how EXACTLY does pixelsearch work? does it scan across from left to right, then move down a line and go again?

Im trying to build it so it resumes where it left off, should what it finds in the pixelsearch not match (that is to say, 1st pixelsearch finds a colour close to what i want, but the 2nd (or even 3rd) which looks for the other colour does not, it will then use pixelsearch again, but with the co-ordinates of the sucessfull pixel search as a start, so it doesnt have to check the whole screen again.

Also, are there any benefits (speed wise) in breaking the screen up into say, 4 sections and simultaniously pixelsearching them as seperate searches?

Thanks!

[SmOke_N]

Im trying to get pixel search to locate an item on screen, but one problem is that the item can be quite varied in its shade of colour, depending on conditions.

there is however, 4 seperate (and very different) colours all close together on the item.

What I want to do, is have pixelsearch look for the first colour with a fairly large tolerance, then when it finds something thats close, to search within a box of xx dimentions around that location for one of the other colours (and possibly a 3rd time for a different colour, to be sure)

My question is, how EXACTLY does pixelsearch work? does it scan across from left to right, then move down a line and go again?

Im trying to build it so it resumes where it left off, should what it finds in the pixelsearch not match (that is to say, 1st pixelsearch finds a colour close to what i want, but the 2nd (or even 3rd) which looks for the other colour does not, it will then use pixelsearch again, but with the co-ordinates of the sucessfull pixel search as a start, so it doesnt have to check the whole screen again.

Also, are there any benefits (speed wise) in breaking the screen up into say, 4 sections and simultaniously pixelsearching them as seperate searches?

Thanks!

I think PixelSearch() goes from Bottom To Top / Left To Right but hey, I've been wrong before lol.

[Devilman]

Cool thanks, so if i wanted to resume, i can just use the coords returned by the pixelsearch as the bottom and left points of the new pixelsearch, yes?

What do you think about splitting the screen up and running multiple instances of pixelsearch? would it be faster or slower in reality?

And is it do-able to have "cascading" pixelsearches, to ensure i do locate what im looking for, and not something else with 1 of the colours i want.

Thanks.

[Devilman]

Remarks

The search is performed top-to-bottom, left-to-right, and the first match is returned.

Earlier versions of AutoIt (prior to v3.0.102) used the BGR format for defining color - newer versions use RGB by default but this can be changed using the ColorMode option.

Thats from the online documentation, so now im confused

[SmOke_N]

Thanks Larry, I couldn't for the life of me remember how you made it.

[Devilman]

SO I asume then that if i were to find the pixel at X co-ord 5, for example, i would have to ditch the rest of that line and resume from X0, Y1?

I cant see this being a huge problem, as the colour(s) im looking for are more than 1 pixel in size anyway, so search next line would (should) still find the right object again.

However can you just comfirm that the online docs are incorrect and that it searches bottom to top (as you said in your post) and not top to bottom like it says in the online documention.

Also does anyone have any views on whether splitting the screen into 4 seperate blocks and running 4 seperate pixelsearch instances at the same time?

Thanks again

[Devilman]

Also Im not sure I could apply the same techniques used in your pixelareafind script, as the colours of the pixels which would be getting "PixelGetChecksum-ed" could be different from when the sample was taken (due to ingame lighting effects etc...) so the area it was checksuming would be different?

Or can that all be delt with by altering the tollerance on the pixelsearch's within the script?

[MuffettsMan]

do i smell a WoW Fishbot?

[Devilman]

do i smell a WoW Fishbot?

LOL perhaps

Lets face it, Fishing is tedious and irritating at best, sitting there staring at the bobber hoping not to miss a bite...

Dont care about AFK fishing, get caught get banned, I just want it so I dont have to actually sit there glued to the screen without blinking, incase i miss the bite, even though I will still be actually watching the game...

As I said lars, the problem I can see is that the colours are not always the same (infact they vary quite a lot depending on the time of day and location in the game) so I cant see how I could use pixelareafind to help me with this?

[CodeMaster Rapture]

As I said lars, the problem I can see is that the colours are not always the same (infact they vary quite a lot depending on the time of day and location in the game) so I cant see how I could use pixelareafind to help me with this?

Back when I had a sub to WoW, just when they re-did the fishing system, I tried to make a dynamic fishbot that worked via PixelChecksum()'s. It's pretty simple, just requires some fine tuning. Here's what I did:

1.) Choose a fishing spot, hit "Start" hotkey

2.) The script will record checksums for 4-8 parts of the screen for 20 seconds

3.) The bot will start fishing looking for an unknown checksum.

4.) *Tricky* Using PixelGetColor/PixelSearch in the checksum region for the bauber and clicking on it

5.) Retrieve the fish and return to #3.

This method isn't designed for AFK use, but could easily be modified to. I would post my code, but Copy & Paste will only get you so far...

-CMR

[Devilman]

I know what your saying Hence my approach being a little different (Cascading pixel searches with a "resume" search), I figured it would be the best way to guarentee Bobber location in most lighting conditions, However am a little concerned on the speed.

Which is why I was wondering about running 4 instances of the pixelsearch'es at the same time (split the screen into quarters and pixelsearch each quarter with its own search, all called at the same time)

Would there be any benefits to this?

[koekje]

Back when I had a sub to WoW, just when they re-did the fishing system, I tried to make a dynamic fishbot that worked via PixelChecksum()'s. It's pretty simple, just requires some fine tuning. Here's what I did:

1.) Choose a fishing spot, hit "Start" hotkey

2.) The script will record checksums for 4-8 parts of the screen for 20 seconds

3.) The bot will start fishing looking for an unknown checksum.

4.) *Tricky* Using PixelGetColor/PixelSearch in the checksum region for the bauber and clicking on it

5.) Retrieve the fish and return to #3.

This method isn't designed for AFK use, but could easily be modified to. I would post my code, but Copy & Paste will only get you so far...

-CMR

I know this is an old post, but how do you search for an unknown checksum? Sounds very complicated to me?