SRL Archive - SRL Archives

for a not-important reason i was looking at MMouse and noticed:

X := x + random(rx);
Y := y + random(ry);

it isn't truly random if it is ALWAYS adding… (:

why not:

X := x + RandomRange(-rx, rx);
Y := y + RandomRange(-ry, ry);

The first will always add to the coordinates, while the second will randomly add or subtract from the coordinates… More randomness if you ask me.
Example:

MMouse(100, 100, 1, 1); right now will move the mouse to:

100, 100

MMouse(100, 100, 2, 2); right now will move the mouse to:

100, 100
100, 101
101, 101
101, 100

MMouse(100,100, 1, 1); with my example change will move the mouse to:

99, 99
99, 100
99, 101
100, 99
100, 100
100, 101
101, 99
101, 100
101, 101

We go from 0(4 if using a 2 for rx/ry) possible outcomes to 9 possible outcomes. This is obviously more random.

x := x + RandomRange(-rx, rx);
y := y + RandomRange(-ry, ry);

Does the same thing as what you put with the exception that I used the correct variables on the second line ;).

From: Sex

x := x + RandomRange(-rx, rx);
y := y + RandomRange(-ry, ry);

Does the same thing as what you put with the exception that I used the correct variables on the second line ;).

thank you. (mind slips sometimes…)
fixed so we can aim the discussion at the reason i posted this as opposed to critiquing me :p

Well we already know. This use used elsewhere in the include iirc.
Random(4) can produce a result of 0..3.
RandomRange(-4, 4) can produce a result of -3..3.
Basically you just double the possible outcomes.

From: Sex
Well we already know. This use used elsewhere in the include iirc.
Random(4) can produce a result of 0..3.
RandomRange(-4, 4) can produce a result of -3..3.
Basically you just double the possible outcomes.

Random(4) can produce a result of 0..3 correct
RandomRange(4) can produce a result of -3..3 incorrect

RandomRange(); is min/max inclusive
thus:
RandomRange(-4, 4); can return -4..4

From: Sex
Well we already know. This use used elsewhere in the include iirc.
Random(4) can produce a result of 0..3.
RandomRange(-4, 4) can produce a result of -3..3.
Basically you just double the possible outcomes.

It can't result as 4!? This is life changing. I never knew this :duh:

From: TomTuff
It can't result as 4!? This is life changing. I never knew this :duh:

haha, the joy in sarcasm, :p

Back on topic, i kinda want someone to tell me why srl isn't using the second example i posted? or tell me that it will be switched to that in the next update ;)

Yes, apologies. My mistake :p. Anyways, yes. I support the change.

It will break backwards compatibility and you can achieve the same result with MMouse(x - rx, y - ry, rx * 2, ry * 2), so it will probably only change in a big release. Although I must admit that I used to think the same as you before I read it in the include.

From: nielsie95
It will break backwards compatibility and you can achieve the same result with MMouse(x - rx, y - ry, rx * 2, ry * 2), so it will probably only change in a big release. Although I must admit that I used to think the same as you before I read it in the include.

Wait, how does it break backwards compatibility?

From: Sex
Wait, how does it break backwards compatibility?

Bitmap finding returns top left point of the bitmap, and several mouse functions (Mousebox?) depend on how it works.

From: Sex
Wait, how does it break backwards compatibility?

the few of us that read the include use:
MMouse(132, 132, RandomRange(-3,3), RandomRange(-3,3));
that really won't be affected.
but if someone coord clicks and adding 1 more to the max or subtracting 1 from the min will affect it(can't really imagine a case in which this could happen) i guess it has the potential of messing it up?

From: TomTuff
Bitmap finding returns top left point of the bitmap, and several mouse functions (Mousebox?) depend on how it works.

i cannot imagine that this is the reason…
MouseBox first picks a random point then moves the mouse to that exact point
MMouse(rpoint.x, rpoint.y, 0, 0);
ABSOULUTELY nothing would be affected if this was changed except the following:
it has the potential of adding -1 or 1 to any randomness… but if your cannot offset your click by 1 pixel you have bigger problems.

Bitmap returning the left top is absolutely the reason to do randomness like this. If you change this, the include breaks. Just use MouseBox instead; and vote for it to be changed in a new SRL.

I would rather see Gaussian distributed mouse methods used..

My mousing methods… it includes what you've mentioned, and incorporates the idea that you as a human click the center of the random area more often than outer parts.

function PtToBox(tile:TPoint;size:integer):TBox;
begin
  Result.X1 := Round(tile.x - size/2);
  Result.X2 := Round(tile.x + size/2);
  Result.Y1 := Round(tile.y - size/2);
  Result.Y2 := Round(tile.y + size/2);
end;

function MouseInBox(box:TBox):boolean;
var pt:TPoint;
begin
  GetMousePos(pt.x,pt.y);
  result := PointInBox(pt, box);
end;

procedure ClickBox(box:TBox;left:boolean);
var x,y:integer;
begin
  x := (box.x2 - box.x1)/2;
  y := (box.y2 - box.y1)/2;
  if not MouseInBox(box) then
    MMouse(box.x1 + x + Random(RandomRange(-x,x)), box.y1 + y + Random(RandomRange(-y,y)), 0, 0);
  ClickMouse2(left);
end;

procedure MoveBox(box:TBox);
var x,y:integer;
begin
  x := (box.x2 - box.x1)/2;
  y := (box.y2 - box.y1)/2;
  if not MouseInBox(box) then
    MMouse(box.x1 + x + Random(RandomRange(-x,x)), box.y1 + y + Random(RandomRange(-y,y)), 0, 0);
end;   

From: Wizzup?
Bitmap returning the left top is absolutely the reason to do randomness like this. If you change this, the include breaks. Just use MouseBox instead; and vote for it to be changed in a new SRL.

will for now… :p

explain what you mean about the bitmap finding relying on how MMouse(); moves??

From: footballjds
will for now… :p

explain what you mean about the bitmap finding relying on how MMouse(); moves??

Well he means Mouse, really. Mouse is the same way btw.

Anyway. FindBitmap() returns the top left pixel of where it was found (I'd like for it to return the center, but whatever), so with scripts that use bitmaps, it will find it and if the randomness includes negative randomness, it has a good chance of not clicking on the bitmap found.

But to fix this we could just get the width and height of the bitmap, div two, and then return that point. (Doing this would make negative randomness work just fine.)

From: i luffs yeww
Well he means Mouse, really. Mouse is the same way btw.

Anyway. FindBitmap() returns the top left pixel of where it was found (I'd like for it to return the center, but whatever), so with scripts that use bitmaps, it will find it and if the randomness includes negative randomness, it has a good chance of not clicking on the bitmap found.

But to fix this we could just get the width and height of the bitmap, div two, and then return that point. (Doing this would make negative randomness work just fine.)

and would make sense.
humans don't click the top left of everything

I made this exact thread a few months back and I'm sure it comes up every once in a while.

It's just how it is for now, :p.

Better wait until SRL 5

Well we already know. This use used elsewhere in the include iirc.

Personally I think it makes sense to return the top left and not the center of the bitmap. What if the bitmap is 3nx3m?

From: Wizzup?
Personally I think it makes sense to return the top left and not the center of the bitmap. What if the bitmap is 3nx3m?

Agreed. However, i do not think MMouse should be used DIRECTLY with the EXACT coords for the found bitmap(unless the bitmap is near the "center" of the object.