SRL Archive - SRL Snippets

BrakeMMouse


Flight

2012-04-19 22:48:51

Hi there,

So while doing some more observation on my own mouse movements another concept stood out. I don't know what a good word would be used to sum it up, but basically slowing down the speed as the mouse approaches it's destination point.

Picture moving your mouse from the main screen (in Runescape) to an item in your inventory. It's a long distance from where you started and you have, basically, a smaller target to hit. Normally, you will move your mouse quickly to get there because of the distance, but will you always remain that fast speed, even drawing nearer and nearer to the item? I personally slow down to make that final distance more accurate. In essence, that's what's done here.

-[Updated 8-20-2012]-

Procedure BrakeWindMouse(xs, ys, xe, ye, gravity, wind, minWait, maxWait, targetArea: extended);
var
veloX,veloY,windX,windY,veloMag,dist,randomDist,lastDist,D: extended;
lastX,lastY,MSP,W,TDist,T: integer;
sqrt2,sqrt3,sqrt5,PDist,maxStep: extended;
begin
MSP := MouseSpeed;
sqrt2:= sqrt(2);
sqrt3:= sqrt(3);
sqrt5:= sqrt(5);

TDist := Distance(Round(xs), Round(ys), Round(xe), Round(ye));
if (TDist < 1) then
TDist := 1;
MarkTime(T);
repeat
if (TimeFromMark(T)>5000) then
break;

dist:= hypot(xs - xe, ys - ye);
wind:= minE(wind, dist);
if (dist < 1) then
dist := 1;
PDist := (dist/TDist);
if (PDist < 0.01) then
PDist := 0.01;

{
These constants seem smooth to me, but
feel free to modify these settings however
you wish.
}

if (PDist >= 0.15) then //15% (or higher) dist to destination
begin
D := (Round((Round(dist)*0.3))/5);
if (D < 20) then
D := 20;
end else if (PDist < 0.15) then
begin
if ((PDist <= 0.15) and (PDist >= 0.10)) then //10%-15%
D := RandomRange(8, 13)
else if (PDist < 0.10) then //< 10%
D := RandomRange(4, 7);
end;

if (D <= Round(dist)) then
maxStep := D
else
maxStep := Round(dist);

if dist >= targetArea then
begin
windX:= windX / sqrt3 + (random(round(wind) * 2 + 1) - wind) / sqrt5;
windY:= windY / sqrt3 + (random(round(wind) * 2 + 1) - wind) / sqrt5;
end else
begin
windX:= windX / sqrt2;
windY:= windY / sqrt2;
end;

veloX:= veloX + windX;
veloY:= veloY + windY;
veloX:= veloX + gravity * (xe - xs) / dist;
veloY:= veloY + gravity * (ye - ys) / dist;

if (hypot(veloX, veloY) > maxStep) then
begin
randomDist:= maxStep / 2.0 + random(round(maxStep) div 2);
veloMag:= sqrt(veloX * veloX + veloY * veloY);
veloX:= (veloX / veloMag) * randomDist;
veloY:= (veloY / veloMag) * randomDist;
end;

lastX:= Round(xs);
lastY:= Round(ys);
xs:= xs + veloX;
ys:= ys + veloY;

if (lastX <> Round(xs)) or (lastY <> Round(ys)) then
MoveMouse(Round(xs), Round(ys));

W := (Random((Round(100/MSP)))*6);
if (W < 5) then
W := 5;
W := Round(W*1.2);
wait(W);
lastdist:= dist;
until(hypot(xs - xe, ys - ye) < 1)

if (Round(xe) <> Round(xs)) or (Round(ye) <> Round(ys)) then
MMouse(Round(xe), Round(ye), 0, 0);

MouseSpeed := MSP;
end;

Procedure BrakeMMouse(eX, eY, ranX, ranY: Integer);
var
randSpeed: extended;
X,Y,MS: integer;
begin
MS := MouseSpeed;
randSpeed := (random(MouseSpeed) / 2.0 + MouseSpeed) / 10.0;
GetMousePos(X, Y);
BrakeWindMouse(X, Y, RandomRange(eX-ranX, eX+ranX), RandomRange(eY-ranY,eY+ranY), 8, 5, 10.0 / randSpeed, 15.0 / randSpeed, 10.0 * randSpeed);
MouseSpeed := MS;
end;

I know 'BrakeWindMouse' and 'BrakeMMouse' are horrible names, but that's all I could think of. Suggestions are welcome. :p

PatDuffy

2012-04-19 22:52:19

Once again another brilliant idea for mouse movements!

I would test it, but I just got in bed for the night. Ill have a go with it tomorrow.

Kyle Undefined

2012-04-19 22:53:23

Hmm, that makes total sense! Awesome work, will give these a go tomorrow :)

Sin

2012-04-19 22:58:51

All your mouse functions NEED to go into the Include :L

halgboy_tbc

2012-04-23 14:07:36

Does this actually matter? If this is suppose to be for safe botting (idk) doesn't Jagex just see where the mouse clicks and the timing of the click, they don't actually track how fast your mouse is going across the screen…?

Abu

2012-04-23 14:23:25

From: halgboy_tbc
Does this actually matter? If this is suppose to be for safe botting (idk) doesn't Jagex just see where the mouse clicks and the timing of the click, they don't actually track how fast your mouse is going across the screen…?


It's all about being more human-like.

Also, what wrong with adding some STYLE in to your script? ;)

halgboy_tbc

2012-04-23 14:28:13

From: abu_jwka
It's all about being more human-like.

Also, what wrong with adding some STYLE in to your script? ;)


I just want to know to make sure I am not overlooking a huge point. In all of my clicks I use randomrange points or offsets and the wait is randomranged as well. So, if I do that, would it matter the if I used a function like this?

masterBB

2012-04-23 14:28:16

From: halgboy_tbc
Does this actually matter? If this is suppose to be for safe botting (idk) doesn't Jagex just see where the mouse clicks and the timing of the click, they don't actually track how fast your mouse is going across the screen…?


Maybe not now, but what if they start doing it? Also it doesn't really hurt anyone. We need functions like this ;)

Imanoobbot

2012-04-23 14:36:28

This seems to be a very human mouse moving methode! Will definietly try this when I am back home.

cause

2012-04-23 15:14:27

From: halgboy_tbc
Does this actually matter? If this is suppose to be for safe botting (idk) doesn't Jagex just see where the mouse clicks and the timing of the click, they don't actually track how fast your mouse is going across the screen…?


I'd agree with you here, it would seem like a waste of resources for jagex to monitor that kind of stuff for individual players, HOWEVER, awesome work Flight!! It is great to look through your code and see the genius :)

Olly

2012-04-23 15:34:09

Why your mouse movements never go in the include I will never know :x

Flight

2012-04-23 22:39:52

It's no biggie if they aren't in the include, that's why I post them here in the Snippets section for anyone to use however they wish.

@halgboy_tbc:
This wouldn't really matter as far as detectability goes. I know for sure Jagex checks for mouse speed, coordinate-clicking, and direction the mouse is moving from point A to point B, I've seen the packets they use to monitor these, they've been keeping track of them for a long time now. Luckily, BenLand100 made our mouse spline that you see in all scripts; a combination of wind & gravity so we're not moving in an absolute straight line. So you're right, we're fine already as far as detectability goes.

I personally, however, enjoy pushing our abilities as to mimicking human interface. I hear a lot about how RiD has some advance mouse movements; "100% like a human", so then why isn't the same said about us? Because we have a spline to pass detection already, so no one bothers to improve more to it, like it's a rule or something.

We have every possible resource to have SRL & our scripts act human, so why stop at just the absolute minimum? I say push on, advance.

Kyle Undefined

2012-04-23 23:49:28

I'm using this in my newest script! It's pretty awesome :)

halgboy_tbc

2012-04-24 17:42:31

Edit: I understand.

I'm not sure how to use procedures like this properly. I see procedures like HumanMMouse, SuperWindMouse in scripts, but they appear to be not used (just stated in the beginning of the script as a procedure) - With BrakeMMouse, SuperWindMouse and the like can I just place them the beginning and they will be applied throughout the script without it being called anywhere?
Idk :(

Gala

2012-04-26 06:43:17

From: halgboy_tbc
Edit: I understand.

I'm not sure how to use procedures like this properly. I see procedures like HumanMMouse, SuperWindMouse in scripts, but they appear to be not used (just stated in the beginning of the script as a procedure) - With BrakeMMouse, SuperWindMouse and the like can I just place them the beginning and they will be applied throughout the script without it being called anywhere?
Idk :(


Instead of MMouse() you call for example HumanMMouse().

This function makes sense for long distances like Mainscreen -> Inventory. I will definitely use this in my next script. :)

Justin

2012-04-26 08:55:35

Fantastic work here Flight!
Will update my scripts to use this function now

ReadySteadyGo

2012-04-26 14:27:15

Love it Flight, going to use this! :P

halgboy_tbc

2012-05-05 19:48:00

This sometimes just moves to the spot and shakes (moves the cursor back in forth in a small area) and stays that way without clicking (going on to the next command).

Recursive

2012-05-05 20:52:00

This really is clever Flight, I especially love how it works in you ZMI script. It's amazing cause ever since I started botting, I have never seen a bot controlling a mouse to move in a not-so-straight but almost snaking movement across the screen. And this is what gives me confidence that it will be impossible to detect bot-like movements when using scripts that use MMouse.

Flight

2012-06-01 00:40:46

Updated the OP. I still continue to work on this over time.

What happens now is as long as the mouse is 30% or higher distance to its target point, the 'step' between each movement will be 1/3 or the current distance. When the mouse comes within 20%-29% the step will decrease to (randomly) between 15 and 18; between 10%-19% the step will decrease once again to (randomly) 10 and 14; and finally when we're under 10% to the target point the step decreases to between 5 and 8.

More steps = slower speed, but also a much smoother mouse motion. If you try out these procedures on a long distance mouse movement you'll clearly see the distance. All of the values can be changed however you wish. Just play around with them and come up with something that fits your own movement style.

Edit:
Oh and Kyle if you read this I have a short message for you. When you first used this in the early stages of your Runespan script people were reporting the mouse "spazzing out", yes? I believe this was caused because of the current step (sometimes) being higher than the remaining distance to the target point. I made sure this couldn't happen anymore in the updated version, but I've only used it in minor testing, you understand. So if you or anyone else would like to give this a longer test run it would help confirm my theory & fix.

Kyle Undefined

2012-06-01 01:03:55

Sweet update! I'll test this with my dev version of the ess script! As always, awesome job! :)

Le Jingle

2012-06-01 01:48:46

Wow, this is exactly what I was thinking of for an ideal mouse procedure. I even experimented for a couple hours to try to have it reduce speed when its oncomming/closing in closer to it's target. This is one heck of a mouse proc, so much gratitude!

Sir R. M8gic1an

2012-06-01 13:38:28

Yay for this :) I've also been looking into it, the IT term is Fitts Law. I'll be working on implementing this into SRL. My current work is mostly related to the size of the Item (the bigger the item the faster the mouse move) and I agree with the steps too. I'd highly suggest using physics law of acceleration to actually deal with it realistically. I made a thread up in devs for this the other day, and there's one im members too about fitts law, you might be interested to read it ;)

~RM

BenLand100

2012-06-01 20:03:44

From: Flight
Luckily, BenLand100 made our mouse spline that you see in all scripts; a combination of wind & gravity so we're not moving in an absolute straight line.

I would like to note, just for clarity, that WindMouse does not use splines. The last mouse methods I wrote did use splines, and that was around for so long that people forever associate 'human mouse movement' with the term 'spline'. Technically 'spline' is a very broad term meaning 'a curve generated from a set of control points' and WindMouse does not fall in that category.

Flight

2012-06-01 21:51:00

From: Sir R. M8gic1an
Yay for this :) I've also been looking into it, the IT term is Fitts Law. I'll be working on implementing this into SRL. My current work is mostly related to the size of the Item (the bigger the item the faster the mouse move) and I agree with the steps too. I'd highly suggest using physics law of acceleration to actually deal with it realistically. I made a thread up in devs for this the other day, and there's one im members too about fitts law, you might be interested to read it ;)

~RM


Well thank you. :) Yes I've thought along the same lines as far as the target area size go. Exactly what you said, the bigger the target the faster we'll move to get there. I also thought we might use the same when choosing an option on a right-click menu; the more options are on the menu, the longer it should take us to choose the correct option. But actually this has nothing to do with BrakeMMouse, just a general suggestion. :P

Yes I read over your thread about that, I think it's a great idea to be honest. Have you begun to fabricate something for the mouse taking into account Fitts Law?

From: BenLand100
I would like to note, just for clarity, that WindMouse does not use splines. The last mouse methods I wrote did use splines, and that was around for so long that people forever associate 'human mouse movement' with the term 'spline'. Technically 'spline' is a very broad term meaning 'a curve generated from a set of control points' and WindMouse does not fall in that category.


Oh ok, I believe I follow now. I thought spline was simply the formula used to calculate a route for the mouse's movement. Seeing as how the next mouse movement is recalculated after each step I guess it really does rule out being a spline.

Thanks for the clarification.

Flight

2012-06-08 21:51:50

Updated it once more. After extensive testing I found at (rare) times there would be a math-related conflict in the procedure; enough to stop the script. So after a couple added failsafes I made sure this could not happen again. I've personally tested it for hours on in, no problems.

Shatterhand

2012-06-09 16:19:52

This is a very nice mouse function. Im using it! :D

Kyle Undefined

2012-06-09 21:33:14

Going to add this back to my Runespan script :)

riwu

2012-06-09 21:46:15

Thanks for the awesome work! Rep++
Another great addition to my personal include :D

The names are awesome, dont worry about it!
I'd probably shorten it for easier usage while scripting though.

Hazzah

2012-06-10 01:05:06

These look amazing. Hoping they make it into the include so that there is never a reason not to use a good mouse movement feature!

Shatterhand

2012-06-20 08:27:41

I had a bug yesterday, this function got stucked. The mouse kept moving around the destination point, I had to stop the script manually.

Le Jingle

2012-06-22 21:11:35

From: Shatterhand
I had a bug yesterday, this function got stucked. The mouse kept moving around the destination point, I had to stop the script manually.


I saw you posted that you were using this, a day after Flight's failsafe addition; in which - are you using the updated code? I experienced the math related conflict, which caused my mouse to try to go beyond the client's dimensions' maximum (x & y)'s. However you did say it was hovering/moving around the destination point, so perhaps you've a completely different error.

Cheers

E: Also noticed that you the original post of Flight's had a ClearDebug; in it towards the end of the BrakeWindMouse. Just thought I'd throw that out there :)

until(hypot(xs - xe, ys - ye) < 1)
ClearDebug;

Shatterhand

2012-06-23 02:52:55

Got that error again, my script could not stop, I think my account got logged out after 30mins because of that 6 hour limit.
I got on video: http://youtu.be/EqMAzmXnLPE
EDIT: I was using the version that was out when I posted first on this topic.

riwu

2012-08-06 08:09:54

Why do you call ClearDebug in the mouse function? No wonder my debug box keep getting cleared recently :p

Flight

2012-08-06 11:48:39

From: riwu
Why do you call ClearDebug in the mouse function? No wonder my debug box keep getting cleared recently :p


Oh it must be from my spline debugger while testing it. I'll remove that now. :P

Shatterhand

2012-08-10 09:59:50

From: Flight
Oh it must be from my spline debugger while testing it. I'll remove that now. :P

Could you look into that bug please what I posted before? :)

tensix

2012-08-19 14:57:31

I have been getting the same error as Shatterhand.
Mouse constantly spinning around the target destination.
Although it seems a very low chance for it to happen, it does happen occasionally.
Any thought on this Flight?

Thanks

Flight

2012-08-19 22:07:28

From: tensix
I have been getting the same error as Shatterhand.
Mouse constantly spinning around the target destination.
Although it seems a very low chance for it to happen, it does happen occasionally.
Any thought on this Flight?

Thanks


Ok I went ahead and modified it to the same as the BrakeWindMouse from MouseHandler V1.02. It's not a proper fix but atleast for now it will won't spam spiral for more than 5 seconds.

tensix

2012-08-21 13:10:16

That's amazing just updated it. Such an amazing mouse function mate, you need them both adding to the include officially. I will test this to the max possible (My script runs 20h+ a day so i will find out soon :P)

riwu

2012-09-08 10:21:23

I discovered that the ranX, ranY parameters in BrakeMMouse are never used, hence no random shift in pixel? Is it meant to be:
BrakeWindMouse(X, Y, RandomRange(eX-ranX, eX+ranX), RandomRange(eY-ranY,eY+ranY), 8, 5, 10.0 / randSpeed, 15.0 / randSpeed, 10.0 * randSpeed);

Flight

2012-09-08 11:46:44

From: riwu
I discovered that the ranX, ranY parameters in BrakeMMouse are never used, hence no random shift in pixel? Is it meant to be:
BrakeWindMouse(X, Y, RandomRange(eX-ranX, eX+ranX), RandomRange(eY-ranY,eY+ranY), 8, 5, 10.0 / randSpeed, 15.0 / randSpeed, 10.0 * randSpeed);


You're right, that was completely left out, good catch Riwu. How shameful, I was so focused on the mechanics that I over-looked such a (missing) basic feature. :/

Olly

2012-09-08 19:00:13

From: Flight
You're right, that was completely left out, good catch Riwu. How shameful, I was so focused on the mechanics that I over-looked such a (missing) basic feature. :/


Ah missing the simplest things…. that always happens :P. At least someone noticed it :P

P1ng

2012-09-17 00:20:11

I would love if this was added to the SRL include, it's an amazing function but too damn big to have in every script :(

Shatterhand

2013-05-17 14:50:53

I really like this mouse function, but its still getting stuck sometimes, like once a week.
http://villavu.com/forum/showthread.php?t=80386&p=1053801#post1053801

Flight

2013-05-17 20:43:21

From: Shatterhand
I really like this mouse function, but its still getting stuck sometimes, like once a week.
http://villavu.com/forum/showthread.php?t=80386&p=1053801#post1053801


Lol it looks funny. I would recommend you pull the AL_BrakeMMouse & AL_MissMouse from the latest MouseHandler that I've been including in scripts lately. Check out either Herb-Farmer or Monkfishies (OSR) to get a copy of it.

It also might be because I didn't put a 'player logged in' check during the 'search for fishing spot' stage.

SecondBest

2013-05-18 13:30:32

hmm would u say this mouse is the best source out right now

Shatterhand

2013-05-19 14:17:54

From: Flight
Lol it looks funny. I would recommend you pull the AL_BrakeMMouse & AL_MissMouse from the latest MouseHandler that I've been including in scripts lately. Check out either Herb-Farmer or Monkfishies (OSR) to get a copy of it.

It also might be because I didn't put a 'player logged in' check during the 'search for fishing spot' stage.

Thanks. So many mouse functions. :)

loragnor

2013-07-31 21:45:41

@Flight, I'm in the process of porting to SRL-6. I love your mouse functions, but there are, of course, some conflicts with the new SRL. Are you planning to update your mouse routines to coincide with SRL-6? There are some particular issues that I've found so far and are fixable. One of the perplexing ones is there is no real replacement for RandomPointBoxEx as used in AL_MouseBoxEx. Nor is there a replacement for WaitUpTextMulti as found in AL_StreamMouse. Any suggestions?

Flight

2013-07-31 22:30:36

From: loragnor
@Flight, I'm in the process of porting to SRL-6. I love your mouse functions, but there are, of course, some conflicts with the new SRL. Are you planning to update your mouse routines to coincide with SRL-6? There are some particular issues that I've found so far and are fixable. One of the perplexing ones is there is no real replacement for RandomPointBoxEx as used in AL_MouseBoxEx. Nor is there a replacement for WaitUpTextMulti as found in AL_StreamMouse. Any suggestions?


Alright, what's the conflict with 'RandomPointBoxEx' in AL_MouseBoxEx? Does it cause compile errors in SRL-6? The same with 'waitUptextMulti'; does this cause compile errors? Admittedly I don't have the SRL-6 library nor was I the one to add these mouse routines to it, but if you tell me specifically what's going wrong I'll surely look into it and have it changed in the include ASAP.

loragnor

2013-08-01 02:39:22

From: Flight
Alright, what's the conflict with 'RandomPointBoxEx' in AL_MouseBoxEx? Does it cause compile errors in SRL-6? The same with 'waitUptextMulti'; does this cause compile errors? Admittedly I don't have the SRL-6 library nor was I the one to add these mouse routines to it, but if you tell me specifically what's going wrong I'll surely look into it and have it changed in the include ASAP.


The conflict is that corresponding functions do not exist in SRL-6. These are the ones I've found:

[table="width: 800, class: grid"]
[tr]
[td]
Existing Code
[/td]
[td]
Replacement Code
[/td]
[/tr]
[tr]
[td]MarkTime(T)[/td]
[td]TTimeMarker.start()[/td]
[/tr]
[tr]
[td]TimeFromMark(T)[/td]
[td]TTimeMarker.getTime()[/td]
[/tr]
[tr]
[td]MMouse(Round(xe), Round(ye), 0, 0)[/td]
[td]MoveMouse(Round(xe),Round(ye))[/td]
[/tr]
[tr]
[td]MSX1, MSY1, MSX2, MSY2[/td]
[td]mainscreen.x1, mainscreen.y1, mainscreen.x2, mainscreen.y2[/td]
[/tr]
[tr]
[td]RandomPointBoxEx(pt,inttobox(x1,y1,x2,y2),Dist)[/td]
[td]!! No equivalent !![/td]
[/tr]
[tr]
[td]SRL_Warn(…)[/td]
[td]print(…)[/td]
[/tr]
[tr]
[td]WaitUpTextMulti(UpTextArr, UpTextWait)[/td]
[td]mainscreen.isUpText(UpTextArr, UpTextWait)[/td]
[/tr]
[tr]
[td]WaitOptionMulti(RClickOptions, OptionsWait)[/td]
[td]chooseOption(RClickOptions, OptionsWait)[/td]
[/tr]
[/table]

My thought was to locate and transpose the required functions from SRL-5 to SRL-6, making whatever changes might be necessary to do so. I had hoped that perhaps you had already considered doing this (or something like this) and either had misgivings or insufficient time to complete it. Or that I was just being impatient. :)

Edit:
K. So, I transposed some functions:

tbox.simba
[table="width: 500, class: grid"]
[tr][td="width: 250"]
Func/Proc Name
[/td][td="width: 250"]
SRL-5 File
[/td][/tr]
[tr][td]BoxClosestPoint[/td][td]math.simba[/td][/tr]
[tr][td]RandomPointBoxEx[/td][td]math.simba[/td][/tr]
[/table]

mouse.simba
[table="width: 500, class: grid"]
[tr][td="width: 250"]
Func/Proc Name
[/td][td="width: 250"]
SRL-5 File
[/td][/tr]
[tr][td]MMouse[/td][td]mouse.simba[/td][/tr]
[/table]

For the most part, it compiles(ctrl-F9) with these changes, though I haven't run it yet. There is an error, however, that makes no sense to me:
Exception in Script: Don't know which overloaded method to call with params (Extended) at line 353, column 27 in file "C:\Simba\Includes\SRL\lib\misc\MouseHandler.simba"
This occurs in AL_WindMouseDTM in the following block:

case Random(50) of
1..25: W := (MSP + (Random((MSP/4)))); // This is line 353 ??
26..50: W := (MSP - (RandomRange((MSP/2), MSP-1)));
end;
if (W < 1) then
W := 1;

Funny thing is, when I compare the SRL-5 and SRL-6 function list for the Math plugins (.dlls, classes, where ever they are actually located), I see that SRL-5 defines RandomRange, Random, and RandomE. SRL-6 only defines RandomRange and RandomE, so I'm not sure how Random is even functioning within SRL-6. And I cannot find any documentation on these funcs anyway. Ideas?