SRL Archive - Research & Development Lounge

In this mouse overload procedure, why is it like this? I can't think of a use

(*
mouse overload
~~~~~~~~~~~~~~

.. code-block:: pascal

    procedure mouse(x, y, randX, randY, button: integer = MOUSE_MOVE);

Moves the mouse to x, y, coords adding random randX, and randY onto x and y,
button is a default parameter and by default is set to MOUSE_MOVE.

.. note::

    - by Olly

Example:

.. code-block:: pascal

    mouse(100, 100, 5, 5, MOUSE_LEFT);
    mouse(100, 100, 5, 5);
*)
procedure mouse(x, y, randX, randY, button: integer = MOUSE_MOVE); overload;
begin
  mouse(point(x+random(randX), y+random(randY)), button); // <---- + random(x)
end;  

Random(x) only returns positive values. For example, random(5) could possibly return 0,1,2,3, or 4.

To explain my problem with this I'll make a picture.

EDIT: PRetend the following circular shapes are rectangles. The issue i'm bringing up is still represented by these pictures but I had a moment of math stupidity when I made this.
The procedure as is will only mouse the orange area. It seems to me that this method was intended to mouse all around the given point. So if one uses

function gaussRangeInt(minI, maxI: Integer): Integer;
begin
  Result := Round(gaussRangeExt(minI, maxI));
end; 

Instead of random(x) like so…

procedure mouse(x, y, randX, randY, button: integer = MOUSE_MOVE); overload;
begin
  mouse(point(x+GaussRangeInt(-randX,randX), y+GaussRangeInt(-randY,randY)), button);
end;  

The effect is (another picture)
So yeah, I don't know if this procedure is working as intended or a mistake. I'm going to use the latter mouse(x,y,ranX,RanY) in my srl regardless, but I figured I would bring this up.

You forgot the green area:


It is kept the same as it was in scar. I dont think there is a reason.

From: masterBB
You forgot the green area:


It is kept the same as it was in scar. I dont think there is a reason.

Ohhhh.. I don't know why I assumed it would be a circle…

oh masterBB, you never fail to amaze

I've pondered this before and the best explanation I could come up with was that moving the mouse strictly in a positive direction, (0, 0) being the top-left, you can never go into the nonsense negative. RS mainscreen has, as far as I remember, always been at the top-left, so you always want to move down and to the right for safety. It's dangerous when we keep doing things simply because "that's how it was always done". But maybe there is a perfectly splendid reason why.

From: fastler
I've pondered this before and the best explanation I could come up with was that moving the mouse strictly in a positive direction, (0, 0) being the top-left, you can never go into the nonsense negative. RS mainscreen has, as far as I remember, always been at the top-left, so you always want to move down and to the right for safety. It's dangerous when we keep doing things simply because "that's how it was always done". But maybe there is a perfectly splendid reason why.

Well if u only move right and down you could go out of bounds as well (beyond max client size).
I think it might be to do with some functions like bitmap finding returning the coordinate of the top left so u can simply use the point returned and the width and height of the bitmap as arguments.

Either way i'd never use that procedure itself, always use the one with gaussbox ;)

Right, but there wasn't ever anything of much importance off to the lower-right side and if you were to go there then you would keep that in mind.
As I know none of my points should be anywhere near the client edge I use mouse like this:

mouse(x + gaussRangeInt(-10, 10), y + gaussRangeInt(-10, 10));

I'm not really sure what the original reason was. But this "problem" was fixed in SRL-5. Unfortunately it caused a bunch of other issues, as the include had a ton of functions that used mouse and had the starting point as the top left w/ a randomness expected to only go down and right. So when the change to mouse occurred it broke a ton of functions. So instead of fixing all those functions, mouse was just reversed to the + only randomness. There's a little history lesson for ya.

For SRL-6, I'm not sure why it was kept. I'm also not sure if any include functions rely on that described in the first paragraph. I think we've used to using more oval and box functions instead, but there is a chance that there are still a lot of functions that rely on the + only principles. You can always change it locally and see if it f's up your include.