SRL Archive - Discussions & Debates

The current MiddleTPA function returns the mean of the TPA. This is often not useful in RS where you want to ensure that the point retrieved lies on the object you are finding.

Eg.

If you get the TPA of the orange color of the copper ore, then splitting it by a distance such that veins from the same ore will be group together, it may result in the adjacent ore being grouped together as well. The resulting point from MiddleTPA could then lie in between the 2 ores, resulting in an unsuccessful click (due to clicking in between the ores).

A more reliable approach could be to get the median of the TPA. The difference between mean and median is that the formal is just a numerical average of the data while the latter is a point that is actually present in the data.
Eg. given an array of Integers: [1, 9, 10, 2, 11], the mean is 6.6, while the median is 9, the middle index in the array (after sorting it by size).

Hence I thought of an alternative function that gets the median of TPA, and since it is a point where the color is found, it will always be a point on the object (and not between 2 obj etc).

function MedianTPA(TPA: TPointArray): TPoint;
begin
  if Length(TPA) < 0 then
    Exit;

  SortTPAFrom(TPA, Point(0,0));

  srl_GaussDev_Range:= 0.1;
  Result:= TPA[iGaussRange(0, High(TPA))];
  srl_GaussDev_Range:= 0.3;
end;     

This would give a random point in the TPA, of which the tendency to choose the points near the middle being much higher. Similar to a normal distribution but with lower deviation.

Would this function be more reliable than MiddleTPA for finding object in RS? And how can it be improved etc? Discuss!


Also can someone explain what a functional pointer is for? Why do we make srl_GaussRand a functional pointer, instead of just calling GaussMarsPolar, or using a wrapper?

This is actually a great idea..

Big time support for this! I've often had this issue with scripts clicking between ores or trees and so forth as a result of this silly MiddleTPA business. Nice work once again riwu

This is a great idea; however, you should make it return the median, not give it a greater chance of returning an index around the median.

As for the Gauss pointer, Nava is the one who wrote those methods, so he would be the one to ask about that.

From: Coh3n
This is a great idea; however, you should make it return the median, not give it a greater chance of returning an index around the median.

As for the Gauss pointer, Nava is the one who wrote those methods, so he would be the one to ask about that.

Yeah originally i thought of just returning the median as well, then usually users will randomize the TPoint by a few pixels. The problem with that is that it may then ended up outside the object.

The idea of this function is that you can ensure your point lies on the object, so i thought of just randomizing it within the function for RS usage.

Possibly another function that just return the median then the users can choose which they wish to?

function MedianTPA(TPA: TPointArray): TPoint;
begin
  if Length(TPA) < 0 then
    Exit;

  SortTPAFrom(TPA, Point(0,0));

  Result:= TPA[Length(TPA) shr 1];
end;

Then rename the above to srl_MedianTPA or something?

And btw the wrapper that resemble MiddleTPAEx:

procedure MedianTPAEx(TPA: TPointArray; out X, Y: Integer);
var
  TP: TPoint;
begin
  if Length(TPA) < 0 then
    Exit;

  SortTPAFrom(TPA, Point(0,0));

  srl_GaussDev_Range:= 0.1;
  TP:= TPA[iGaussRange(0, High(TPA))];
  srl_GaussDev_Range:= 0.3;

  X:= TP.x;
  Y:= TP.y
end;

I've already replaced MiddleTPA with these functions in my scripts for testing.

If you're just randomizing the point (not the index of the point) then there isn't much point because scripters are going to randomize the point they're moving the mouse to, like:

p := medianTPA(tpa);
mmouse(p.x, p.y, 5, 5);

So if you add randomness, they're going to add more.

If you're randomizing the index of the result TPoint, then it makes a little more sense, in which case you should have two functions.

Also, if you have it return the actual median, it can be added to Simba. ;)

From: Coh3n
If you're just randomizing the point (not the index of the point) then there isn't much point because scripters are going to randomize the point they're moving the mouse to, like:

p := medianTPA(tpa);
mmouse(p.x, p.y, 5, 5);

So if you add randomness, they're going to add more.

If you're randomizing the index of the result TPoint, then it makes a little more sense, in which case you should have two functions.

Also, if you have it return the actual median, it can be added to Simba. ;)

What do you mean by 'randomizing the point'? I think i am indeed randomizing the index of the TPA, and hence a random point in the TPA (with a higher tendency of it being closer to median). So there will not be any need for the user to add randomness. Or if they want they can still add 1-2 pixel of randomness. (to make it more human-like in that you aren't always clicking on the exact points with color).

My function in post #5 does indeed return the median directly. For array with even number of data, like [1,2,3,4], would you consider 2, or 3 to be the median? Mathematically both of them can be considered the median but it only make sense to return one of them.

Also my srl_GaussDev_Range of 0.1 is rather arbitrary, Nava2 could possibly suggest a better number? Or keep it at 0.3?

Coh3n meant that most people use like P := MiddleTPA(ATPA) and then Randomize Point P. If you are already randomizing the median people will randomize it again. However, if you know that the function randomizes then there is no point in adding more randomness. But I'm sure some people will still add randomization to a randomized outcome.

From: riwu
My function in post #5 does indeed return the median directly. For array with even number of data, like [1,2,3,4], would you consider 2, or 3 to be the median? Mathematically both of them can be considered the median but it only make sense to return one of them.

It doesn't matter either way in my opinion.

By the sounds of it you're randomizing the index, which is fine. I still think you should have a function that returns the actual median (which should go in Simba), MedianTPA. A randomizedMedianTPA function or something can be placed in SRL.