SRL Archive - Suggestions

Well I've had this algorithm in my head for a long time. Just never had time to implement this correctly..

First start with a practical use of this algorithm, and then we can go into the actual algorithm: For example we want to find an Al-kharid warrior.

We can create a lot of advanced colour finding stuff to find this warrior, based on it's purple colour etc.. However we know more about this warrior. We know for example that besides the colour purple, it contains the color brown and grey.

So what if we just do simple FindColors searches on those 3 colours, and find a "densed" area where all of those 3 colours overlap.. We then pretty sure know that this 'area', must be an alkharid-warrior. As you can see it would be pretty easy 'object' finding, just pass 3 colours to an function and let it return a TPoint.

As you probably noticed this looks a lot like DTMs, but then without the relative distances between the point, thus making it more dynamic.

Such a algorithm needs a few parameters, this is what I could come up with. (note that the colour finding is done before you use this algorithm)

• Goodpoints (ATPA)
• BadPoints (ATPA)
• Box-size (Width/Height) where in the points must exist
• Percentage of how much of the box must (or not) be a certain colour

I did that in my lumby miner years ago (with 2 colours though)

Yes! I have wanted a system like this for a long time, but I just haven't made one yet / been lazy.
We totally need this.

I think similar results can be obtained by combining the 3 (or x) TPA's, then use TPAToATPAEx (passing the box size stuff) then comparing the length of the resulting TPA's to see if one is long enough - for percentages, (length * 100) / (width * height) >= percentage.

From: mixster
I think similar results can be obtained by combining the 3 (or x) TPA's, then use TPAToATPAEx (passing the box size stuff) then comparing the length of the resulting TPA's to see if one is long enough - for percentages, (length * 100) / (width * height) >= percentage.

:confused: Pretty sure you then rule out the fact that multiple different colours must be in the same area..

Ahh, if you were to insist on multiple different colours, then it becomes a bit longer.

Get the 3 TPA's, TPAToATPAEx, get TPABounds for all the TPA's, find overlapping boxes in all three ATPA's that relate to the colours - afaik RM added a box overlap/intercept function to the includes or there is one floating around somewhere.

From: mixster
Ahh, if you were to insist on multiple different colours, then it becomes a bit longer.

Get the 3 TPA's, TPAToATPAEx, get TPABounds for all the TPA's, find overlapping boxes in all three ATPA's that relate to the colours - afaik RM added a box overlap/intercept function to the includes or there is one floating around somewhere.

Possible, however that method will flail when you start adding more and more colors :p

This algo is supposed to kinda, first create a default box.. then move it around the mainscreen, until you find a perfect match. While yours first gets some boxes, and then tries to match them. Is indeed faster, but less accurate :).

You just be hating.

Anyway, in terms of implementing your version, the problem would be in where do you base the centre of the distance from?

I mean, you would get an area of colour A, but do you then base the distance between points of colour A and B on a single point, or the centre of a group of points that fall within a box of given width and height or ones that are within range of any points in a group of points or what! There's just too many different ways to implement it, each one with differing outputs - from very accurate, but unlikely to return results to very inaccurate, but likely to return results.

From: mixster
You just be hating.

Anyway, in terms of implementing your version, the problem would be in where do you base the centre of the distance from?

I mean, you would get an area of colour A, but do you then base the distance between points of colour A and B on a single point, or the centre of a group of points that fall within a box of given width and height or ones that are within range of any points in a group of points or what! There's just too many different ways to implement it, each one with differing outputs - from very accurate, but unlikely to return results to very inaccurate, but likely to return results.

I 'r hatin'!

But, yes, you are right. However you must admit that this iz z3h leet object finding :p

Indeed it may be, but I don't see it being quick enough after you use 3 or more colours - 2 may be ok, but definitely 3 would require such large boxes that the searching would become insane!

So something like this?

1: Divide target area (pretty much MS) into boxes (pretty much tiles). Do this again, except with the corners of the second set of boxes being in the centers of the first set, either right away and do all of the following steps twice, or go through the steps with the first set of boxes, and only do the second set if the results from the first set are not satisfactory.
2: Starting from the center box and go out in a spiral pattern.
3: For each color get a tpa for the box. Filter by sizes/counts/densities etc, then give it a score.
4: Depending on parameter (or make it two functions)
a: Stop when you get to a box with a good enough score (maybe do a text check)
b: do all the boxes (either first set or both), and then sort by score, and return an array of scores+Tpoints, letting the user decide what to do.

I think 4b is better, unless it's really slow.

Guys, why would you want something like this on a global level? Not many people are going to make use of it and if you're going to even bother doing something advanced like this it's more worth your while to make something entirely customized to a specific purpose for practical reasons.

The problem lies in the implementation - after it is, then it can be used to make things like FindObjTPA more accurate and offer improved complex object finding for people who may want to use it.

Humm… I've thought of something like this several times, but couldn't quite think of how to implement it.

Idea…:
Get the TPAs for 2/3 colors
TPAToATPAEx (boxing them).
TPAToTBox
Find Overlapping boxes
Re-analyse the boxes that overlapped to sort out which one is best, or
Re-analyse the boxes starting from the center, until a good enough one is found
Move mouse, if uptext then all is good, otherwise continue analysing boxes.

~RM