SRL Archive - Development

This is what I've been working on for fun for the past 2 weeks or so. I spent the last 2 weeks studying calculus and statistics to learn how to apply this to a script. (I've only taken up to Pre-Calc in school, so learning it on my own was tough, but fun). When I wasn't at my computer this past week, I was with my cousin getting stoned, which without that I wouldn't have half the ideas of the various functions I tried. I tried at least 15 different methods before getting this one. My cousin played X-Box 360 and I'm next to him stoned researching calculus functions with a little notebook of mine filling up 15 pages of potential methods :P.


It's a clicking function which bases its click randomization off a Two-Dimensional Gaussian Distribution Function. Meaning the clicks have a probability Density to them.

The function which I base the generation and selection off of generates a graph like this.


the function I applied it with was:


Meaning the majority of clicks if measured in the long run will be closer to the center point that is selected. There's a probability density of more clicks towards the center selected point.

The reason this is better than the procedure Mouse(mousex, mousey, ranx, rany: Integer; left: Boolean); included in srl is…… the mouse function generates click offset of a random amount of points from the selected click origin. Since I recently read up on how jagex is improving their macro detection system(because they told how :P), they said they can pretty much look at someones clicks and see if they're falling within a certain box.

My function generates more of an accuracy where more clicks will fall closer to the inputted point in the long run. This was VERY tough to figure out since the only random function in scar is a uniform random function… yet after some experimenting I figured out how to make most of the randomizations land closer to the higher accuracy. Meaning there is a MUCH higher chance of landing closer to 90% than 10%, so it's very human like if aiming towards a general area.

My coding style is fairly messy(or atleast the formatting) compared to other scripters I've seen on here, but nontheless it works.

It is in the beta because I plan to make many more improvements to it.

One major thing I plan to add is…… when a player is going towards a click(say a rock or something in the inventory), I can make it so depending on the direction the click is coming from, there will be a higher chance to Overshoot the click.
-Say the click is coming from below the object… depending on the distance the mouse is from the object before the click, the click may overshoot the item and accidentally click directly above it(missing the item). This is very very human like behavior, of course I will incorporate the vectors so it can work at all angles. I hope to have this done in a week or so, if not less.

I made an attempted to annotate the script to point some things out. The part where the actually clicking takes place can be changed. I have it set to use ClickMouse, which obviously isn't a good function for autoing on runescape. You will have to go in and change it to whichever clicking function you wish to use, Mouse, MMouse, etc. I used Clickmouse for convenience of testing in Paint so I could visually see where all the clicks landed.

This script below is outdated and more efficient versions have been posted by numerous people throughout the thread.

Procedure RadialClick(x1,y1,R:Integer);
var
xc,yc,xo,yo,oy,ox,BoxBounds,iR,iR2,c,xoff,yoff:Integer;
z:extended;

begin
ox:=R  //X Radius
oy:=R  //Y Radius
xo:=x1   //X Center for accuracy Basis
yo:=y1   //Y Center for accuracy Basis
BoxBounds:=ox+ox;
//This additional plus to get points of <30% accuracy.
//Box Variable is to prevent point scanning outside of potential circle
//iR:=RandomRange(RandomRange(Random(100),100),100)
{This randomization you see above^, is an alternative to the one below
The one above is much more accurate. I have not measured the difference
between the two, but the way I designed it to work, the one above is much
more accurate. Personally I would use the bottom one
}
iR:=RandomRange(Random(100),100)

for xc:=-BoxBounds+x1 to BoxBounds+x1 do
begin
for yc:=-BoxBounds+y1 to BoxBounds+y1 do
begin

begin
z:=(100*Exp(-1*((sqr(xc-xo)/(2*sqr(ox))) + (sqr(yc-yo)/(2*sqr(oy))))))

if ((trunc(z) = Ir)) then
begin

iR2:=Random(3)
if c >= IR2+1 then
begin
xoff:=(x1-xc)
yoff:=(y1-yc)
      Case random(2) of
      0:xoff:=xoff;
      1:xoff:=-xoff;
      end;
      Case random(2) of
      0:yoff:=yoff;
      1:yoff:=-yoff;
      end;
      
      Case random(2) of
      {CHANGE CLICK MOUSE TO WHATEVER CLICKING FUNCTION YOU WANT,
      MOUSE,MMOUSE. i USED CLICKMOUSE FOR SIMPLICITY OF TESTING CLICKS
      IN PAINT.}
      0:ClickMouse(x1+xoff,y1+yoff,true);
      1:ClickMouse(x1+yoff,y1+xoff,true);
{ The reason I have this in a case is to randomly invert the offsets
What this does is maintain the accuracy of the original offset
while creating even larger variation.}
      end;

      Exit;

      end;
      c:=c+1

end;
end;
end;
end;
end;

How to use it:
RadialClick(x1,y1,R:Integer)

x1 and y1 are obvious where you desire the general clicking area to be. R, is the pixel radius of the circle. I used 15 for most of my testing, the lower the radius, the smaller the click area will be. Also clicks may be missed if it is lowered lower than 10, though this is easily fixed. This is just a beta, but I plan on having any clicking errors fixed in the next few days as I test it more with different inputs.

For RS purposes, just use 15 as the radius, as this will cover most items in the inventory, rocks, etc.

Also Warning: A lot of calculations takes place in the function. Meaning if you increase the radius over 20-25 then there may be a delay in generating the click. This depends though on the speed of your computer.

I scripted this on a Quad Core processor with 4gig ram and the delays seemed to be nothing at 15 radius. If it does delay for you, the delay wont be that big, a 50-200 miliseconds if that. If you find it laggy you can play with the radius. The delay should not be a problem unless you're trying to do clicks VERY fast and very repetitive(like several clicks a second), which I see no need for in RS.

Anyways, in the next version I plan on fixing it so it runs faster with a more effective method and incorporating the chance of over clicking depending on the direction the mouse comes from.

Part of The Jagex post which inspiried me:

The second criteria is the "accuracy" of the clicks. The interface determines exactly where any specific click was made, and is further divided into the actual buttons such as the inventory, worn equipment, etc…
Primitive programs typically recognize the object, but click the same spot (often the same pixel.) This immediately raises the alarm if it is done consistently. Most programs do not do this, though, but rather have an "area of uncertainty" where the click will randomly fall in.
This is still easy to detect. There is accuracy, and precision. These programs do not replicate human precision. Consider the dartboard as an example:
The goal is to simply "hit it." A human will still aim for the bullseye, to increase the chance of hitting the dartboard. Thus hits will be concentrated towards the bullseye, but there will still be hits nowhere close, and some misses too.
A macro does not have human flaws, and can always hit the dartboard. However, if randomized in the "area of uncertainty" there is no such pattern."

This will also raise the alarm. More advanced yet, some macros will actually form concentric regions of where the clicks will land. Still, we're always ahead of rulebreakers. Our final line of defense in this criteria is to analyze the regions most commonly clicked.

As explained above, my function DOES replicate precision… and by the time I incorporate potential overclicking depending on the approaching direction and distance, it will be nearly 100% human like. None of the clicking functions I have seen around are close to that.

After putting this code together for the past week or so, I'm beginning to think that the Gaussian function was not even necessary for my desired result, but I feel it will play an important roll when I go to add the random overshooting when moving the mouse to a point which is far away.

I don't even play runescape anymore lol, but I like coding and thwarting rules I see as unreasonable. That is also the reason I largely create wall hacks and aimbots for FPS games, though I'm still practicing at that… even though I don't really have an interest in them lol.

This script is no where efficient as it could be, but its intended function works extremely well. I have many more improvements to make. The only potential fault in the script currently is if the radius area to click in is too large, this can cause large delays in click, but I don't think it's anything you need to worry about for RS botting. I should have the potential delay due to large calculations fixed soon(I hope lol)

Coding/Scripting is fun.

interesting. I didn't read all of your explanation but it seems cool. If you used this in conjunction with SRL's MMouse and Mouse I think it would be pretty nifty.

Ya, It would be neat if people could test it out and say how it goes. I feel it is MUCH safer than other clicking methods…. but other clicking methods are safe, unless you are reported… If you're reported using this clicking function, they shouldn't be able to tell if you're a human clicking or a bot clicking. All the other botting actions are up to you, the screen rotations and such. Time between clicks, length of time mouse is held down, etc.

Also if you see any potential way to improve its speed while maintaining function, please do say so.

I just did this other test in terms of how accurate the clicks are.

I had two methods for accuracy generation.
The second one is more accurate… Here are where the clicks landed out of two 1000 click trials. The first one is the one automatically enabled in the script, it can be changed if desired.

RandomRange(Random(100),100)

0.9% of clicks are in the 0% to 10% range
2.2% of clicks are in the 10% to 20% range
4.1% of clicks are in the 20% to 30% range
6.8% of clicks are in the 30% to 40% range
8.3% of clicks are in the 40% to 50% range
9.4% of clicks are in the 50% to 60% range
9.8% of clicks are in the 60% to 70% range
16.2% of clicks are in the 70% to 80% range
19.1% of clicks are in the 80% to 90% range
31.7% of clicks are in the 90% to 100% range

and

RandomRange(RandomRange(Random(100),100),100)

0.0% of clicks are in the 0% to 10% range
0.1% of clicks are in the 10% to 20% range
0.9% of clicks are in the 20% to 30% range
1.1% of clicks are in the 30% to 40% range
2.4% of clicks are in the 40% to 50% range
3.1% of clicks are in the 50% to 60% range
6.5% of clicks are in the 60% to 70% range
12.4% of clicks are in the 70% to 80% range
24% of clicks are in the 80% to 90% range
55.9% of clicks are in the 90% to 100% range

The results are rounded to the decimal, so the 0% up there isn't 0%, it's just very very small. Which is why I prefer the first function. Though these are subject to modifications to change up precision.

Jagex potentially 'could' use the above results to detect this script, but it is unlikely because this is very human like and the percentages very by 2-3 every run or so, because it is partially random, yet uses precision.

The method is subject to change to be more human like, so if they actually did use these results to ban other botters, they would ban a lot of legit players, since this is based off human like clicking precision.

I've thought about this too :) I don't understand your code, but good job anyways.

Nice work! Keep at it :)

Still, we're always ahead of rulebreakers.

I lol'd

I love how much you are reading and how much time you are putting in to this. Good job. Don't give up!

Very interesting. Didn't read all either, will later. Don't have it overshooting the clicks and misclicking, as otherwise you'd have to correct the click and so on.

What I would consider is the direction & speed that the mouse movement has could affect the ending place, meaning that if it is coming from south-west it could tend to end up more in North-East direction from the 'real' place where it should end up.

~RM

Now, I, for one, did read it all. Quite interesting, too.
I had no idea JaGeX were upgrading their anti-bot-system, but we can rest assured that they're not a step forward and hardly even less than 5 steps behind.

This seems like a very good idea and function, not least.
Your scripting is, as you say, pretty messy but if the code works there should be nothing to worry about. Your research and time put into this is quite phenomenal and I like your attitude. Programming is fun even if you don't play RS ;) I agree with you here.

I like the fact that RandomRange(Random(100),100)) favors higher numbers, and the more times you put in RandomRange, the more higher numbers are favored. Very smart.

Very good job, thus far. But before this gets implemented, somebody will have to rewrite the code. But the credit will be all yours ;)

procedure RadialClick(x1, y1, R: Integer);
var
  xc, yc, xo, yo, oy, ox, BoxBounds, iR, iR2, c, xOff, yOff: Integer;
  z: Extended;
begin
  ox := R;
  oy := R;
  xo := x1;
  yo := y1;
  BoxBounds := ox + ox;
  iR := RandomRange(Random(100), 100);
  for xc := -BoxBounds + x1 to BoxBounds + x1 do
    for yc := -BoxBounds + y1 to BoxBounds + y1 do
    begin
      z := (100 * Exp(-1 * ((Sqr(xc - xo)/(2 * Sqr(ox))) + (Sqr(yc - yo)/(2 * Sqr(oy))))));
      if(Trunc(z) = iR)then
      begin
        iR2 := Random(3);
        if c >= IR2+1 then
        begin
          xOff := (x1 - xc);
          yOff := (y1 - yc);
          case Random(2) of
            0: xOff := xOff;
            1: xOff := -xOff;
          end;
          case Random(2) of
            0: yOff := yOff;
            1: yOff := -yOff;
          end;
          case Random(2) of
            0: ClickMouse(x1 + xOff, y1 + yOff, True);
            1: ClickMouse(x1 + yOff, y1 + xOff, True);
          end;
          Exit;
        end;
        Inc(c);
      end;
    end;
end;

From: Rasta Magician
Very interesting. Didn't read all either, will later. Don't have it overshooting the clicks and misclicking, as otherwise you'd have to correct the click and so on.

What I would consider is the direction & speed that the mouse movement has could affect the ending place, meaning that if it is coming from south-west it could tend to end up more in North-East direction from the 'real' place where it should end up.

~RM

That's the point, it should misclick ossionally. Like jagex said, bots don't tend to misclick, humans do often. It would be a rare missclick in this case. Any halfway good script SHOULD have fail safes are the clicks anyways to ensure the game didn't lag and never registered the click.

The second paragraph is exactly what I intended. (when I get to adding it)

From: King of Knives
Now, I, for one, did read it all. Quite interesting, too.
I had no idea JaGeX were upgrading their anti-bot-system, but we can rest assured that they're not a step forward and hardly even less than 5 steps behind.

This seems like a very good idea and function, not least.
Your scripting is, as you say, pretty messy but if the code works there should be nothing to worry about. Your research and time put into this is quite phenomenal and I like your attitude. Programming is fun even if you don't play RS ;) I agree with you here.

I like the fact that RandomRange(Random(100),100)) favors higher numbers, and the more times you put in RandomRange, the more higher numbers are favored. Very smart.

Very good job, thus far. But before this gets implemented, somebody will have to rewrite the code. But the credit will be all yours ;)

I know. It is very far from being finished. Right now what it does is, after it does the random and favors the higher number, is cycles through a ton of numbers which can cause lag if the Radius/area to search in is set to high. What it does is, it plugs each coordinate into the formula and checks its accuracy relative to the original point. I already have many ideas for changing this and making it 50x faster.

From: i luffs yeww

procedure RadialClick(x1, y1, R: Integer);
var
  xc, yc, xo, yo, oy, ox, BoxBounds, iR, iR2, c, xOff, yOff: Integer;
  z: Extended;
begin
  ox := R;
  oy := R;
  xo := x1;
  yo := y1;
  BoxBounds := ox + ox;
  iR := RandomRange(Random(100), 100);
  for xc := -BoxBounds + x1 to BoxBounds + x1 do
    for yc := -BoxBounds + y1 to BoxBounds + y1 do
    begin
      z := (100 * Exp(-1 * ((Sqr(xc - xo)/(2 * Sqr(ox))) + (Sqr(yc - yo)/(2 * Sqr(oy))))));
      if(Trunc(z) = iR)then
      begin
        iR2 := Random(3);
        if c >= IR2+1 then
        begin
          xOff := (x1 - xc);
          yOff := (y1 - yc);
          case Random(2) of
            0: xOff := xOff;
            1: xOff := -xOff;
          end;
          case Random(2) of
            0: yOff := yOff;
            1: yOff := -yOff;
          end;
          case Random(2) of
            0: ClickMouse(x1 + xOff, y1 + yOff, True);
            1: ClickMouse(x1 + yOff, y1 + xOff, True);
          end;
          Exit;
        end;
        Inc(c);
      end;
    end;
end;

I didn't use Inc because Inc© is slower than c:=c+1;.


There's some bad news though. I woke up this morning with a 'crick' in my neck and it hurts like a bitch lol. I'm about to go lay back down and I don't feel like doing anything till it heals because the pain constantly is distracting me. It shouldn't delay me for too long. I already have all the changes I want to make in my head, its just a matter of implementing them.

I can play with the equation and get the X coordinate on one side, then do it again for the y coordinate.

This way once I have the target percentage to aim for I can have it loop and find accurate coordinates in like 3-5 loops, which would be MUCH faster than the 3000+ loops per click it's doing up there with the coordinates…..

If anyone wants to play around with the equation and help me move around the variables that would be good.

When "xc" and "yc" are in putted into the function with the other variables, the z output is the percentage accuracy. I have it multiplied by 100 to ease the number comparison so I'm not dealing with decimals the whole time. I'm going to need to go and change most of the variables to extended when I rearrange the variables in the function.

(what I do often is just go post the problems on yahoo answers if I'm stuck and get tips there :P, which I'm about to go do because when rearranging the equation I get stuck at a point where there is a -ln() to counter the exp^, and that goes under a squareroot which gives me a math error. )

From: Rasta Magician
Very interesting. Didn't read all either, will later. Don't have it overshooting the clicks and misclicking, as otherwise you'd have to correct the click and so on.

What I would consider is the direction & speed that the mouse movement has could affect the ending place, meaning that if it is coming from south-west it could tend to end up more in North-East direction from the 'real' place where it should end up.

~RM

If by that you mean a tendency to overshoot to the north-east I'm not sure I agree.

If you mean that there will be a larger range in SW-NE axis than in the perpendicular axis, I think that's probably true.

More like an oval shape, centered at the destination point, with the shorter axis perpendicular to the mouse path.

From: tarajunky
If by that you mean a tendency to overshoot to the north-east I'm not sure I agree.

If you mean that there will be a larger range in SW-NE axis than in the perpendicular axis, I think that's probably true.

More like an oval shape, centered at the destination point, with the shorter axis perpendicular to the mouse path.

I believe I can do that. The other day when I was playing with the equation, I found a way to make it so each radius of the x,y can be bent and ovalised. I forgot what I did exactly but I can easily figure it out again.

I worked abit on my own version of this theory. Mine doesn't use any fancy shmancy Guassian Distribution because that's a bit over my level.
Mine simply favors numbers through the "RandomRange(Random(X),x)"-method.

Here's a distribution of my function versus the randomness we currently use when botting.
A good showcase into why this is actually important for us to do.

And here's a showcase of the angular selection I've implemented into mine. The sector used here is from 300 degrees to 400 degrees.

Probably not as good as yours. My distribution is like this:

0-10%: 334 (33.4%)
10-20%: 191 (19.1%)
20-30%: 145 (14.5%)
30-40%: 122 (12.2%)
40-50%: 67 (6.7%)
50-60%: 58 (5.8%)
60-70%: 37 (3.7%)
70-80%: 27 (2.7%)
80-90%: 15 (1.5%)
90-100%: 4 (0.4%)

But it does the job quite well.

The code:

{/////
Point of Human Randomness.
Uses favoring of the points closer to the center
Can be set to only choose points in certain degrees.
PARAMS:
x,y: The original coordinate
R: Radius of circle of randomness around point (x;y)
SD: Start-degree of sector of circle, the point can be in
ED: End-degree of sector of circle, the point can be in
/////}
Function PointOfHR(x,y,R,SD,ED: Integer): TPoint;
var
 RandomDegree,RandomRadius,h: Integer;
begin
  //If the start-degree is larger than the end-degree, they are swapped
  if (SD > ED) then
  begin
    h:= SD;
    SD:= ED;
    ED:= H;
  end;

  //A random degree between SD and ED is selected.
  RandomDegree:= RandomRange(SD,ED);

  //Selects a random radius from 0-R. Favors lowers radiuses for
  //increased human-like results. (Use commented function below
  //to favor higher numbers even more)
  //RandomRadius:= R-RandomRange(RandomRange(Random(R),R),R);
  RandomRadius:= R-RandomRange(Random(R),R);

  //With both a random degree and random radius, a random point
  //within the boundaries selected can now be calculated.
  Result.x:= Round(x+RandomRadius*sin(Radians((RandomDegree+0.0))));
  Result.y:= Round(y+(-RandomRadius)*cos(Radians((RandomDegree+0.0))));
end;

-Knives

EDIT: Figured out I should perhaps show you the code.

EDIT 2: Tested the speed of the function. I let it get me a point with a radius of 300 (Way more than you'd ever use in RS) and full-circle randomness. It ran the function 1000 times in 31ms :)

Interesting. Mine is very slow right now due to the method, but I am working on improving it. The Gaussian distribution isn't as complicated as you think.

I may merge pieces of our method together.

Looking at yours… I can implement the RandomRange(Random(100),100)) into yours for a more probability density generation type thing.

I'll try it out and play with it and post back.

edit:

I actually think yours is better in general lol.

Though I'm still going to attempt to incorporate angular vectors depending on the direction it comes from… As for the the " fancy shmancy Guassian Distribution "… you're function DOES incorporate it. It incorporates it by the method which it generates the clicks.

Well, it might not be very complicated, I don't know. I just made a quick function of the idea I had in my mind. And I didn't really feel like reading up on Gaussian Distribution, since I felt like doing a quick coding.

The only problem with mine, as it is now, is that it favours the centerpoints a bit too much, I think. But I also use simple functions, which I think makes the difference in speed. It works as intended and the angular selection works, so it's really just the radius-randomness that could be more advanced.

Let me know what you come up with ;)

From: King of Knives
Well, it might not be very complicated, I don't know. I just made a quick function of the idea I had in my mind. And I didn't really feel like reading up on Gaussian Distribution, since I felt like doing a quick coding.

The only problem with mine, as it is now, is that it favours the centerpoints a bit too much, I think. But I also use simple functions, which I think makes the difference in speed. It works as intended and the angular selection works, so it's really just the radius-randomness that could be more advanced.

Let me know what you come up with ;)

I'm going to run 1000 of the points that yours generates through the same method I used to measure the accuracy of my points.

This way I can see the actually accuracy of the points. I will edit/post back in a few-30 minutes.

edit:

The overall output of yours when ran through the Gaussian distribution function. I'm not sure how you calculated your accuracy.

82.1821821821822% of clicks are in the 90% to 100% accurate
13.7137137137137% of clicks are in the 80% to 90% accurate
5.00500500500501% of clicks are in the 70% to 80% accurate
1.4014014014014% of clicks are in the 60% to 70% accurate
0% of clicks are in the 50% to 60% accurate
0% of clicks are in the 40% to 50% accurate
0% of clicks are in the 30% to 40% accurate
0% of clicks are in the 20% to 30% accurate
0% of clicks are in the 10% to 20% accurate
0% of clicks are in the 0% to 10% accurate

90%-100% being extremely close to the center point.

It works, but I'm experimenting to try to figure out why it never touches the 0%-60% accuracy range.

Though I don't think yours can be measured the same.

I'm not sure if yours is actually putting more points towards the center, or if it just looks like that because it may just be putting the same amount of points over a certain area.

meaning, there may be like 20 some points in the 60s range, 20 some in the 90s range, 20 some in the 10 range…


Edit: The difference between mine and yours is the accuracy of my points are based upon the normal distribution. While the accuracy of yours is based upon the RandomRatio/MaxRatio, meaning different distribution of points. Meaning something like…. your accuracy is based upon a linear scale, and mine is based on a Gaussian curve scale. Meaning yours could work, but the point distribution is kind of odd.

Yours also generates the points seperately, yet on the same accuracy…. which ultimately results in a flux in accuracy of the point as a single point, when it was generated as 2 separate points. … The equation I am using is generating the points at the same time factoring in the accuracy of both in combination.

Mine will be able to do 1000 clicks in under a second when I get the next feature of mine implemented.. I just need to rearrange the Gaussian formula which is proving to be sort of difficult at the moment. Not sure why lol.

CX Gamer already made something like this about a week ago. I would love to see a mashup of what you two guys did, because (if I understood well) you made the arrival point more human while he made the mouse speed and direction so.

From: Cigue
CX Gamer already made something like this about a week ago. I would love to see a mashup of what you two guys did, because (if I understood well) you made the arrival point more human while he made the mouse speed and direction so.

Very interesting. I think when I get finished with mine, his in combination with mine would ultimately be the most perfect human replication of clicking.

I would like to see jagex use clicks as a way of banning after that.

If this goes well and works as well as I predict to enhance botting, then the entire botting community may adopt the method, along with those using RSBot and other Javabots.

I find that very…interesting that we both happen to make attempts at Mouse functions botting wise, both using Gaussian functions, both within a week or 2 of eachother :P. Maybe it's the same article that inspired us…

Though… I don't think Jagex can detect mouse movements. For jagex to record all mouse movements, that would be a ridiculous amount of storage space. Even if it is just 60 seconds after/before you were reported.

I think the only thing jagex measures is timing between clicks, click accuracy, etc.

Heres the article which jagex talks about their macro detection system(this is very recent)

The only thing they mention about Mouse MOVEMENTs is extremely fast movements. It's VERY unlikely that they record the exact spline of a mouse movement. Though it still is possible, just unlikely.

Our macro detection system is highly advanced, reminiscent of our efforts to curb rule breakers prior to the removal of unbalanced trade. Admittedly, we devote more of our energies towards introducing actual game content.

The use of macros is nevertheless unacceptable, and contrary to popular belief we have not ignored the recent outbreak of bot usage. Modern macros however are quite advanced, rarely interact with the client, and issue commands the same way players point and click, rotate the camera, etc… We presume this sudden leap of sophistication to be due to the fear of being caught with well developed accounts, as most macro users seldom use throwaway accounts. Many recent macro users actually have comparable gameplay hours to legitimate players.

[name removed], I don't actually know the very specific details. It's likely that nobody knows the entire system to the letter, given the vastness of all of the software involved.

Firstly, we only issue bans if we can beyond a reasonable that the individual in question has committed a violation of the rules. We have stated this to the public quite a bit, and it really is true. I wouldn't lose sleep over the bans we've issued at all.

Our actual detection system monitors player behavior autonomously. As most bot programmers have unfortunately and conveniently guessed, it works on a comparison of expected human behavior to the observed behavior. Thus, macros that follow a set series of commands would be incredibly easy to catch, if they would even be operational. Random camera shifts usually thwart these, and finding them is a very rare occurrence.

We regularly dismantle macros, and the most common approach taken is object recognition with a series of programmed responses. One of our very first attempts to counter this was random color changes, usually not very noticeable. This turned out to be a failure as object recognition technology proved to be far ahead of this eventuality."

"Unless the appearance of the interface was changed sufficiently enough to make it unusable to even a regular player, it was not practical to make the game unrecognizable to a macro program.
All that we could do was analyze rather than inhibit, so to speak. By determining sets of behaviors that are not characteristically human, in "criteria", we would get the alarm from the system if all were met.
The first criteria is quite a bit similar to that of most first person shooter (FPS) games who take steps to detect "aimbots." This would be simple movement. Inhumanly fast cursor movements are highly suspicious, and consistent patterns of such movements (to discern from some player who gets bored and plays with the mouse .) I don't know the actual numbers involved, sorry. Some exceptionally skilled players frequently do trigger this, which is why multiple criteria exist.
The second criteria is the "accuracy" of the clicks. The interface determines exactly where any specific click was made, and is further divided into the actual buttons such as the inventory, worn equipment, etc…
Primitive programs typically recognize the object, but click the same spot (often the same pixel.) This immediately raises the alarm if it is done consistently. Most programs do not do this, though, but rather have an "area of uncertainty" where the click will randomly fall in.
This is still easy to detect. There is accuracy, and precision. These programs do not replicate human precision. Consider the dartboard as an example:
The goal is to simply "hit it." A human will still aim for the bullseye, to increase the chance of hitting the dartboard. Thus hits will be concentrated towards the bullseye, but there will still be hits nowhere close, and some misses too.
A macro does not have human flaws, and can always hit the dartboard. However, if randomized in the "area of uncertainty" there is no such pattern."
********Which is why I need to implement randomly overshooting a click.********
This will also raise the alarm. More advanced yet, some macros will actually form concentric regions of where the clicks will land. Still, we're always ahead of rulebreakers. Our final line of defense in this criteria is to analyze the regions most commonly clicked. *****To combat this, we combine the Gaussian click generation, with a random variation in the targeted clicking area by a 2-3 pixels. This way the clicks are still accurate, but never revolve around a single pixel****
A macro tends to click in a perfect square, circle, or sometimes the shape of an interface icon. Sometimes even the region is randomized. Human behavior is not truly random however. The region most commonly clicked is related to placement, which is all I know about this.
Highly advanced bots have made an attempt to replicate even this, but we have not seen anything convincing yet. Admittedly, we're disadvantaged in this aspect, so we cannot fully rely on simple movement and accuracy to detect a macro program.
The next criteria is the actual sequence of actions. A player that decides to cut some trees for logs, and sell them for profit actually has a longer list of actions to perform than you'd think. The efficiency of which this is completed can be analyzed, and much more easily compared to the behavior of a macro programs' attempt to replicate it.
If each step is merely randomized with the same bounds of uncertainty like virtually all bots seem to do today, the actual time it takes to execute the actions in all converges to a specific value! It's similar to flipping a fair coin multiple times, and converging to a frequency of outcomes (namely 50%.) Humans are generally much less consistent, and once the consistency falls within a certain range, the alarm is raised.
One more of many criteria is the effect of total gameplay time. As expected, exhaustion will set in for most players and slow down their actions. This is not a completely reliable method, since some players have been able to keep up their concentration for remarkably long periods of time."

"The last criteria I really know of is probably the most obscure and advanced. Human players tend to have much better object recognition capabilities than a macro program, and the limitations of the procedure can be exploited. While a human may be able to recognize a tree at a very unusual and discrete angle, many macros lack this capability, and thus keep the camera angle within a certain range. Some fail to change it entirely. ******This is combated with Java bots or reflection*******
Macros tend to locate objects that are far out of reach by going close to the area in question, and then finding it. Normal players tend to look ahead first.
There are probably many more techniques employed, and the genius and innovative capability of my coworkers is simply amazing. I am very confident in their ability to enforce the rules, and keep RS a fair, and equal environment. The detection system is definitely conducive to such, but that is not our only method.
The next is abuse reports. There are many new and better bots, just written, that can avoid at a few of the criteria, and not be flagged. The intuition of a human being can never be surpassed, and abuse reports give us an all seeing eye that brought many rule breakers to justice. Abuse reports are also helpful for locating the archives, and comparing the new behavior of the new macro that was previously able to avoid detection. We can update accordingly.
We highly encourage abuse reporting, and we will not punish players who send in reports with a reasonable cause to suspect the player in question is using a macro.
Circumstances (such as the usual range of playing time) is taken into account as well.

By the way, what I posted was just standardized. You can change Inc back to var := var + 1; if you want.

Also, not everything they say they can really monitor. They have more important things to do than constantly watch everyone's clicking habits. Botting does not matter to them as long as nobody complains. They're a business. Remember that.

That was an interesting read.

From: i luffs yeww
By the way, what I posted was just standardized. You can change Inc back to var := var + 1; if you want.

Also, not everything they say they can really monitor. They have more important things to do than constantly watch everyone's clicking habits. Botting does not matter to them as long as nobody complains. They're a business. Remember that.

They don't watch everyone's clicking habits, it's programmed so that when the clicking habits aren't "human" they'll get notified.

Here's the article in pdf: http://rs-hacking.com/resources/macroingdetection.pdf

I've had thoughts of going to work for jagex before.. at least if I was in the UK lol.

I have a very easy method to catch 99% of the botters in RS that's 100% full proof. I've debated on posting it on here before, but I rather wouldn't incase Jagex stumbled upon it.. I know they don't have it implemented either or there would be no botters on RS. That's how good the system I have devised it.

That was a great read, I do think that this could be implemented better, and in a more reasonable approach. Also, I don't think you have pure Gaussian Distribution. I will try to write up a true distribution function.

I think that this could be modified to use with (M)Mouse for SRL's clicking. I would rather see something along these lines than the typical random box. Knives has a very valid point.

I do not understand why your function has so many loops going in it, that is why it would be slow.

The application of a 2D gaussian function is very nice though :)

I have an algorithm for applying a distribution, I just have yet to see how I will apply it.

It is an very nice article indeed. And would be awesome if we can improve on all those points. More miss clicks should be added yes. Rsbot totally fails on the camera angle, but that's something to watch with reflection to. Don't click objects that aren't visible. Good job on the mouse function.

It would be perfect to have the "speed flow" in the movements, the "randomness", and the "miss clicks".

I added the article to my signature, because I think it would really be an eye opener to some scripters.

From: MasterKill
<snip>

I added the article to my signature, because I think it would really be an eye opener to some scripters.

Reading that makes me wonder though. SRL lands in the range that the report claims to be observable and detectable, example randomness in a square, perfect mouse moving (as in accuracy wise), never slowing, keeping the camera fix, etc. So you begin to wonder, If everything that SRL is doing can be detected, why are SCAR/Simba scripts rarely ever detected?

From: Blumblebee
Reading that makes me wonder though. SRL lands in the range that the report claims to be observable and detectable, example randomness in a square, perfect mouse moving (as in accuracy wise), never slowing, keeping the camera fix, etc. So you begin to wonder, If everything that SRL is doing can be detected, why are SCAR/Simba scripts rarely ever detected?

Because some people actually do click in box areas.


Usually if you're reported, you're more than likely going to get caught. If you're autoing with normal MMouse and Mouse functions and don't get reported, you wont get caught… though if you're reported, they can analyze the clicks and catch you.


With a Gaussian function, even if you are reported, they'll have a hard time catching you, as long as your movements and actions are randomized. The gaussian mouse function is just 1 step closer to making scripts more human like.

This also should be implemented over the current MMouse Function:http://villavu.com/forum/showthread.php?t=58201

From: Nava2
That was a great read, I do think that this could be implemented better, and in a more reasonable approach. Also, I don't think you have pure Gaussian Distribution. I will try to write up a true distribution function.

I think that this could be modified to use with (M)Mouse for SRL's clicking. I would rather see something along these lines than the typical random box. Knives has a very valid point.

I do not understand why your function has so many loops going in it, that is why it would be slow.

The application of a 2D gaussian function is very nice though :)

I have an algorithm for applying a distribution, I just have yet to see how I will apply it.

Feel free to post any ideas. Anything to better the method.

I am still looking for help on rearranging the function, so if you want to help me with that. I've posted an explanation on what I need help with here:
http://www.physicsforums.com/showthread.php?t=420958

I'm still learning calculus and I haven't had a math class for a year or so… meaning I've forgotten some of the rules for rearranging functions.

I know my script is far from perfection, but its a start for a general idea in what we should be doing.

Make it into a function and return true when it misclicks.

From: Smartzkid
Make it into a function and return true when it misclicks.

For that to be done you would need to know every single pixel that would count as clicking the item.

Meaning if you're clicking a GameTab(square shape), and its set to a circle radius, it could still return a missclick, but have actually hit it.

Meaning for it to actually return true if it missclicks you would have to know each pixel that is an acceptable click… Or else it would return true for a missclick if you actually hit it, and depending on how complex the action is, it could try to redo an entire set of actions when it never failed in the first place.

That's why it's better to set up your own fail safe to check to see if the click landed… Like after telling it to click a gametab box, actually check to see if that gametab appeared.

PointInBox(Point(x, y), TBox); ?

From: r!ch!e
PointInBox(Point(x, y), TBox); ?

That's not what I'm saying… the game does not work strictly off perfect square boxes. Neither does the Two-Gaussian Distribution function.

Besides that, if you had it only clicking in a box, that would defeat the purpose of what we're trying to do.

Unless I am misunderstanding what you're saying…. Care to elaborate?

I dont think that the function should ever misclick. Because you could easily click on the ground somewhere and walk to a different location and it could mess up the script.

From: lordsaturn
I dont think that the function should ever misclick. Because you could easily click on the ground somewhere and walk to a different location and it could mess up the script.

Yeah but what human doesn't missclick. Besides, what you're referring to is clicking objects like rocks and other objects across the landscape. Meaning the position of these objects should change which also means it doesn't matter which clicking function is used.

When I designed this it was strictly for clicking things on the interface where area of the clicks are often the same, such as when alching or fletching.

When you're searching for rocks and clicking them, the variation would have to lie within the function which finds the colors. Because simply rotating the screen which would move the location of the rock(locally to the screen) would result in a different clicking area, meaning the Gaussian click function wouldn't matter because the local position of the object on the screen is changing. If your screen isn't rotating at all then you're script probably isn't very good… No screen movement for long periods is how jagex catches people.

From: Xtensity
No screen movement for long periods is how jagex catches people.

I never move the screen when I play legitly. Bad way of detecting botters in my opinion.

Perhaps return an extended with the percentile at which the function clicked?

While your argument is valid, it doesn't make sense to not give the scripter information on where their script is clicking. Knowing that information is a great boon.

From: Smartzkid
Perhaps return an extended with the percentile at which the function clicked?

While your argument is valid, it doesn't make sense to not give the scripter information on where their script is clicking. Knowing that information is a great boon.

How is that really that useful to the user? Just curious

From: Smartzkid
Perhaps return an extended with the percentile at which the function clicked?

While your argument is valid, it doesn't make sense to not give the scripter information on where their script is clicking. Knowing that information is a great boon.

That's how I have it during the debug when I am modifying it. I only changed it to a procedure for posting it here and cleaned up majority of the WriteLns that were in the script. Remember this is just a beta and I already have a better version I am still working on. I just have many other things to do also.

That can be done very easily. In the script, Z is the percentage. All you do is change it to a function and make it return extended. Right after the point is calculated, whatever that Z is, that is what is returned.

But tell me how that is going to help the autoer? He would have to know on the screen where the 10%-X range is located at in order to create a failsafe to combat it.

Sure it can be done, but how it is being applied to a fail safe is dependant on the type of script.

From: Frement
I never move the screen when I play legitly. Bad way of detecting botters in my opinion.

It depends what activity you are doing, if you're talking etc…. You're telling me when you're running around going to various locations, you NEVER move the screen?

From: Xtensity
Yeah but what human doesn't missclick. Besides, what you're referring to is clicking objects like rocks and other objects across the landscape. Meaning the position of these objects should change which also means it doesn't matter which clicking function is used.

When I designed this it was strictly for clicking things on the interface where area of the clicks are often the same, such as when alching or fletching.

When you're searching for rocks and clicking them, the variation would have to lie within the function which finds the colors. Because simply rotating the screen which would move the location of the rock(locally to the screen) would result in a different clicking area, meaning the Gaussian click function wouldn't matter because the local position of the object on the screen is changing. If your screen isn't rotating at all then you're script probably isn't very good… No screen movement for long periods is how jagex catches people.

No where earlier in this post have I seen you declaring that this function was made to be used only for inventory and interface functions. In fact one of the scenarios you give is clicking on a rock. If you do plan to implement this misclicking feature, this function should not be implemented into MMouse, it should be implemented into a MMouseGauss function perhaps with a paramater that gives the % chance of misclicking as Smartzkid suggested.

As Frement suggested, some players do not move the camera while playing runescape. Therefore it is not absolutely necessary to implement camera rotation into your script. Camera rotation could possibly be difficult to manage , and in some cases even break the script. In other cases the script may be impossible to function without a constant pitch and yaw. Or the scripter may simply not want to implement the camera rotation, because of the added workload. In all cases, it is not mandatory, but recommended.

I had camera rotation in my guard killer and it worked pretty good, it was in antiban procedure, and when it started walking (i used DTM's) and FindDTMRotated so it didnt matter what angle the MM was. Only in bank it set compass to south to find the bank booth.

Anyway, I really don't think this function should ever miss click.

EDIT:

From: Xtensity
You're telling me when you're running around going to various locations, you NEVER move the screen?

Last time I moved the screen was when I tested SRL's InFight function.

From: lordsaturn
No where earlier in this post have I seen you declaring that this function was made to be used only for inventory and interface functions. In fact one of the scenarios you give is clicking on a rock. If you do plan to implement this misclicking feature, this function should not be implemented into MMouse, it should be implemented into a MMouseGauss function perhaps with a paramater that gives the % chance of misclicking as Smartzkid suggested.

As Frement suggested, some players do not move the camera while playing runescape. Therefore it is not absolutely necessary to implement camera rotation into your script. Camera rotation could possibly be difficult to manage , and in some cases even break the script. In other cases the script may be impossible to function without a constant pitch and yaw. Or the scripter may simply not want to implement the camera rotation, because of the added workload. In all cases, it is not mandatory, but recommended.

I know I didn't state it was directly for inventory use, that's not the point I'm trying to make. This function is to provide variation when clicking in the same spots over and over again. If you're running around with it and clicking rocks then I don't think it would be necessary. I figured almost all legit players move the screen when playing constantly. If my hand isn't on the keyboard typing it's usually moving the screen around so I can more easily click what I am trying to click.

Tell me this. If you're trying to attack a monster, Say he's a little bit to far below your screen, what do you do? Do you click 1 tile downwards, then click the monster? Or do you simply move the screen, then click it? Which is easier? Moving the screen is easier. I have never met a legit player who doesn't move the screen for long periods of time, unless that player is doing a stationary action such as fletching, alching, or mining the same 2-3 rocks that surround him.

In that case, if he is clicking the same rocks over and over again, chances are he wouldn't misclick. This is because the missclicking feature was originally going to be implemented only if the target clicking spot is quite a distance away from the current mouse pos. This is because they quickly jerk the mouse to get to that far away distance which often results in overshooting the movement.

Does Reflection not have a function to locate tiles incase the player is mislocated? I'm not saying it must have a chance of missclicking. If players don't want it to missclick I can make it so they simply set the chances to 0%. It's not a hard feature to implement.


If I'm not mistaken… isn't one of the common anti bans in SRL moving the screen angle? When I do implement the miss-clicking option, sure I can allow for the player to set how often it missclicks.


Again I'm open to ideas for this and if you actually have a method for creating a feature, then please post it.

From: Xtensity
I know I didn't state it was directly for inventory use, that's not the point I'm trying to make. This function is to provide variation when clicking in the same spots over and over again. If you're running around with it and clicking rocks then I don't think it would be necessary. I figured almost all legit players move the screen when playing constantly. If my hand isn't on the keyboard typing it's usually moving the screen around so I can more easily click what I am trying to click.

Tell me this. If you're trying to attack a monster, Say he's a little bit to far below your screen, what do you do? Do you click 1 tile downwards, then click the monster? Or do you simply move the screen, then click it? Which is easier? Moving the screen is easier. I have never met a legit player who doesn't move the screen for long periods of time, unless that player is doing a stationary action such as fletching, alching, or mining the same 2-3 rocks that surround him.

In that case, if he is clicking the same rocks over and over again, chances are he wouldn't misclick. This is because the missclicking feature was originally going to be implemented only if the target clicking spot is quite a distance away from the current mouse pos. This is because they quickly jerk the mouse to get to that far away distance which often results in overshooting the movement.

Does Reflection not have a function to locate tiles incase the player is mislocated? I'm not saying it must have a chance of missclicking. If players don't want it to missclick I can make it so they simply set the chances to 0%. It's not a hard feature to implement.


If I'm not mistaken… isn't one of the common anti bans in SRL moving the screen angle? When I do implement the miss-clicking option, sure I can allow for the player to set how often it missclicks.


Again I'm open to ideas for this and if you actually have a method for creating a feature, then please post it.

I agree with your points. Misclicking and camera rotation are very good antiban features to have, and should be implemented, backed by that article mentioned earlier in the thread.
However it would be disastrous to scripters to change the number of parameters in Mouse, as all scripts would break. For now (SRL 4) MMouseGauss or MMouseMisclick. In the future (SRL 5), we can change the MMouse parameters for misclicking when all of the scripts are going to have to be updated to use the new include.

From: lordsaturn
I agree with your points. Misclicking and camera rotation are very good antiban features to have, and should be implemented, backed by that article mentioned earlier in the thread.
However it would be disastrous to scripters to change the number of parameters in Mouse, as all scripts would break. For now (SRL 4) MMouseGauss or MMouseMisclick. In the future (SRL 5), we can change the MMouse parameters for misclicking when all of the scripts are going to have to be updated to use the new include.

I know what you mean about changing the number of parameters in Mouse would be an issue, very easily we can just make MouseGauss/MMouseGauss as you stated…. I understand what you're saying, and the problem is very avoidable by creating a new function… Perhaps when I said it should the Gauss function should replace the Mouse function, I should have stated it in a different manner.

They would require different inputs. The Gauss function does not have a place for potential offsets like (x,y,xoff,yoff). It would have different inputs totally and if scripters wanted to replace their Mouse Functions with the new one, then it would be an easy change. I don't see why they wouldn't want to change it. Of course the missclick is optional.

But yes, I shouldn't have said for this to replace the other Mouse Function, as they operate differently… I just don't see anyone actually still using the Mouse function after this function comes out, as this one would be much safer in terms of antiban.

From: Xtensity
I've had thoughts of going to work for jagex before.. at least if I was in the UK lol.

I have a very easy method to catch 99% of the botters in RS that's 100% full proof. I've debated on posting it on here before, but I rather wouldn't incase Jagex stumbled upon it.. I know they don't have it implemented either or there would be no botters on RS. That's how good the system I have devised it.

/me hopes Camo Developer isn't here.

PM it to me pl0x? :D

I'll find ways to counter it…. hopefully.

You neede x and y variables extracted, right, Xtensity?
I used my math program for school (TI InterActive) and I just plotted the function in and had it extract x and y. I may have done something wrong, so here's the entire thing.

I just plotted in the names of the variables and all that. The names for the x- and y-radii is just ax and ay. Don't worry, the program doesn't mess up with variable names, it knows the difference between ax and A*x :D

I hope it helps, but I'm not sure it's done the way you want.

-Knives

Nice work.

It would be interesting if someone made a script that records and graphs mouse clicks while playing legit. Even better if it could take into account approach angle.

From: Boreas
Nice work.

It would be interesting if someone made a script that records and graphs mouse clicks while playing legit. Even better if it could take into account approach angle.

Yep, that is exactly what I plan on implementing. After I post the newer updated version in a day or 2 thanks to King of Knives for helping with that formula… then maybe you all can help me with some ideas of incorporating the approach angle.


I have an odd feeling I will need to incorporate vector calculus, but I hope that isn't the case lol, because I haven't gotten around to learning that yet.

Also if anyone is wondering the site I'm using to learn all this math from nothing.

http://www.khanacademy.org/

Best site I've ever found lol. 1 Guy from harvard teaching almost all subjects from K-12 and up to the first 2-3 various math semester of college

From: King of Knives
You neede x and y variables extracted, right, Xtensity?
I used my math program for school (TI InterActive) and I just plotted the function in and had it extract x and y. I may have done something wrong, so here's the entire thing.

It looks pretty accurate, I'm going to try it right now

Ok. Knives I took the formula and put it in scar format(atleast I tried..)

It works, but not correctly and I can not figure out what I did wrong.

Here's the script for testing the numbers.

If anyone can help me find where the error is that's not making it generate the right numbers, it would be a great help lol.

program New;
var
x,z,ax,y,yo,ay,xo:Extended;
function ln(e:Extended):Extended;  begin result:=lnxp1(e-1); end;
begin
ClearDebug;
ax:=15;//X Radius;
ay:=15;//Y Radius;
xo:=0//x Center
yo:=0//y Center
y:=0 
z:=0.50;//Percentage, this should make z:=.50 on lower equation
X:= -((ax - sqrt((-sqr(y))+(2*yo*y)+(2*(ln(1/z )*sqr(ay)-0.50*sqr(yo))))-ay*xo)/ay) //This is function from knives.
z:=(Exp(-1*((sqr(x-xo)/(2*sqr(ax))) + (sqr(y-yo)/(2*sqr(ay))))))//This function checks accuracy of point
writeln(z) //This should be generating a 0.50 dead on, but it isn't.
           //It generates a number of .990000001 ~ .99999999

end.

I asked for help from the people on PhysicsForum, and they keep telling me hints on how to do it lol. Hints of things I already know they do not help me at all with the errors I get….. Yet they still keep telling me hints of things that are irrelevant to my issue.

Don't you think you should also calculate y, instead of setting it to 0 ? I'm not sure if that will fuck up the program or is completely unnecessary, I just thought I'd say it ;)

From: King of Knives
Don't you think you should also calculate y, instead of setting it to 0 ? I'm not sure if that will fuck up the program or is completely unnecessary, I just thought I'd say it ;)

I'm just doing this as a test to be sure that the reversed equation actually works…

Then what I can do is cycle through like 10-20 Y values until I find a working Y value… instead of doing the other method where I cycle through 3000 different combinations of X and Y.

The little script there is just a debug to be sure the equation works correctly… and it doesn't lol. Not sure why, which is why I'm asking for help :P.

The x value that is generated in that test script is unimportant. What is important is if the generated X value in combination with the inputted Y value equals the inputted percentage, but it doesn't.

Once I get it generating an X value which accompanies the Y which results in the exact inputted percentage, then I can round the points to be whole numbers.

I see what you've done wrong. But I won't tell you.
Just kidding. Of course I will :p (I MADE A FUNNY)

Let me etch it up more clearly ;)

You've misread some of the multiply-signs (*) with minuses (-) :D I've done it a quadrazillion bajillion times with that program, but if I'm not mistaken, that should be what you did wrong :D

From: King of Knives
I see what you've done wrong. But I won't tell you.
Just kidding. Of course I will :p (I MADE A FUNNY)

Let me etch it up more clearly ;)

You've misread some of the multiply-signs (*) with minuses (-) :D I've done it a quadrazillion bajillion times with that program, but if I'm not mistaken, that should be what you did wrong :D

damn!.. Seriously lol, I misread like all of them at first… then I went back and corrected it… but I missed the the ax * sqrt one. It works now. I should have the script working much faster in a day or so, right now I need to go out and do somethings.

If you have potential theory on any cool mechanisms we could implement then post them.

From: Xtensity
damn!.. Seriously lol, I misread like all of them at first… then I went back and corrected it… but I missed the the ax * sqrt one. It works now. I should have the script working much faster in a day or so, right now I need to go out and do somethings.

If you have potential theory on any cool mechanisms we could implement then post them.

Haha, I messed up on it quite often in the start, aswell.

Good to hear about the program. Sadly, I do not have any idea of mechanics we could implement, but I think it's quite powerful enough ;)

If anyone has a link to a tutorial on try/catch/except/finally, that would be great. I can't find a tut anywhere on here about them and they are vital for finishing this script… Because even if I'm only running through 30 numbers, math errors occur, which crash the script.

edit: nvm figured it out.

edit:Try allows me to call something IF a math error occurs…. is there any way I can make it call something if a math error DOES NOT occur?

edit: Nvm I figured I just put what I want to happen right after the equation that could cause an error

edit: Alright… it's coming along very very nicely. It's already 10x faster. I'll be implementing it in the function later tonight. Once I have done this the only thing it will be missing is the angular vector potential for missclicking, Which isn't that important, so I'll figure that out later.

Well, I'd just like to post this here, these are my results with my algorithm. I use an algorithm from a professor, so I don't know if I can FOSS it or not.

SRL's algorithm:

My version:

Side by side:

For 300 trials:

SRL::   T: 16ms Each: 0.05ms
Gauss:: T: 78ms Each: 0.26ms

Yeah mine is going to be around that fast when in a bit. Just trying to get some methods worked out.

From: Nava2
Well, I'd just like to post this here, these are my results with my algorithm. I use an algorithm from a professor, so I don't know if I can FOSS it or not.

SRL's algorithm:

Side by side:
">">

Can you post the script? Because there was a method I saw that only allowed the clicks to land within a circle region. Though yours seems to spread them.

This is all I have right now, it takes around 1-2ms per function execution. Much faster than the first thing I posted lol.

Function MouseGauss(xc,yc,r:Integer):Extended;
var
TP:TPoint;
x,z,y,ax,yo,ay,xo:Extended;
begin
ax:=r;//X Radius;
ay:=r;//Y Radius;
xo:=0//x Center
yo:=0//y Center
y:=0
z:=(RandomRange(RandomRange(0,100),100)/100)+0.01
repeat
y:=Randomrange(-r,r)
try
X:= -((ax * sqrt((-sqr(y))+(2*yo*y)+(2*(lnxp1((1/z)-1 )*sqr(ay)-0.50*sqr(yo))))-ay*xo)/ay)

x:=round(x)

case Random(8) of
0:TP:=IntToPoint(round(x),round(y));
1:TP:=IntToPoint(round(-x),round(-y));
2:TP:=IntToPoint(round(x),round(-y));
3:TP:=IntToPoint(round(-x),round(y));
4:TP:=IntToPoint(round(y),round(x));
5:TP:=IntToPoint(round(-y),round(-x));
6:TP:=IntToPoint(round(y),round(-x));
7:TP:=IntToPoint(round(-y),round(x));
end;
ClickMouse(TP.x+xc,TP.y+yc,true)//This can be changed to either return the point or click with another function

Exit;//Exit loop after finding working random Y to match Equation
except
end;
until(false)
end;

Yours may be better though, I'm not sure what your script does.

function MouseGauss(xc, yc, r: Integer): Extended;
var
  TP: TPoint;
  x, z, y, ax, yo, ay, xo: Extended;
begin
  ax := r;//X Radius;
  ay := r;//Y Radius;
  xo := 0;//x Center
  yo := 0;//y Center
  y := 0;
  z := (RandomRange(RandomRange(0, 100), 100)/100) + 0.01;
  repeat
    y := Randomrange(-r, r);
    try
      x := -((ax * Sqrt((-Sqr(y)) + (2 * yo * y) + (2 * (Lnxp1((1 / z) - 1) * Sqr(ay) - 0.50 * Sqr(yo)))) - ay * xo) / ay);
      x := Round(x);
      case Random(8) of
        0: TP := IntToPoint(Round(x), Round(y));
        1: TP := IntToPoint(Round(-x), Round(-y));
        2: TP := IntToPoint(Round(x), Round(-y));
        3: TP := IntToPoint(Round(-x), Round(y));
        4: TP := IntToPoint(Round(y), Round(x));
        5: TP := IntToPoint(Round(-y), Round(-x));
        6: TP := IntToPoint(Round(y), Round(-x));
        7: TP := IntToPoint(Round(-y), Round(x));
      end;
      ClickMouse(TP.x + xc, TP.y + yc, True)//This can be changed to either return the point or click with another function
      Exit;//Exit loop after finding working random Y to match Equation
    except end;
  until(False);
end;

What's lnxp1? :p

lnxp1 is ln(e+1)

for some reason, Ln isn't even in the Scar coding… yet some odd modified version is there… The one i needed for this code was Ln….. Ln(e) = Lnxp1(e-1)

Ask freddy why it wasn't in there lol.

I did that in Simba. Haven't used SCAR for awhile.

From: i luffs yeww
I did that in Simba. Haven't used SCAR for awhile.

The main reason I use scar is because I haven't gotten around to adding the numerous functions that simba lacks which scar has via a plugin.

Mine is in Simba, I'm going to email my professor now. To see if I can use this in a GPL environment.

From: Xtensity
The main reason I use scar is because I haven't gotten around to adding the numerous functions that simba lacks which scar has via a plugin.

What functions? They can simply be added..

I really don't understand why people don't suggest things that aren't in Simba to be added. :/

From: i luffs yeww
What functions? They can simply be added..

I really don't understand why people don't suggest things that aren't in Simba to be added. :/

Well a lot of functions from delphi in general need to be added…

Function Erf(x: Extended): Extended;
Function Ln(x: Extended): Extended;


Those are the only 2 I can think of off the top of my head. I know there are several more but I'm having a thought loss right now.

There's also quite a bit relating to arrays that I can't think of at the moment.

Is it that difficult to simply import all delphi functions? Or do the functions need to be done 1 by 1.

If Simba could be a fully functional live delphi compilier with all delphi functions.. that would be amazing.

edit: I also notice Function Lnxp1(x: Extended): Extended; isn't in Simba…. There's a lot of crucial math functions accelerate the development of better autoing functions, or any functions in general.

>_> Well I wouldn't say this has anything to do with better autoing. To be honest there is no point to this at all. But whatever. I'll suggest these.

Actually, may I ask some actual uses for these? Apart from this single thing which is a waste of time, of course.

(first is 3000 amounts, second is 5000 amounts)

Spreads aside an Incoming Angle, or completely random.

program new;
const
  w = 250; //Width
  h = 250; //Height
  amount = 3000; //Amount of dots to draw
  SpreadFactor = 10; //Spread from the centre
  IncomingAngle = 90; //Angle at which you approach the center, 0..360
  AngleSpread = 2.3; //Spread from the incoming angle, -1 for complete random
var
  bmp : TMufasaBitmap;
  i : integer;
  Dist : extended;
  RandomNum : extended;
  cntrx,cntry : integer;
  pixels : TPointArray;
  angle : extended;
begin
  DisplayDebugImgWindow(w,h);
  bmp := TMufasaBitmap.create;
  bmp.SetSize(w,h);
  setlength(pixels,amount);
  cntrx := w/2;
  cntry := h/2;
  Writeln(IncomingAngle / 180.0);
  for i := 0 to amount-1 do
  begin
    if AngleSpread = -1 then
      angle := Random(9999) / 9999.0 * 2* pi //Angle between 0..2pi
    else
    begin
      angle := (pow(Random(9999) / 9999.0,AngleSpread)) * pi;//Random number between 0..pi
      if random(2) = 0 then
        Angle := IncomingAngle / 180.0 * pi+ Angle
      else
        Angle := IncomingAngle / 180.0 * pi - Angle;
    end;
    RandomNum := Random(9999) / 9999.0; //Between 0..1
    dist := (pow(randomnum,SpreadFactor));
    pixels[i] := point(Round(cos(angle) * dist * (cntrx-1) + cntrx), Round(-sin(angle) * dist * (cntry-1) + cntry));
  end;
  bmp.DrawTPA(pixels,clred);
  DrawBitmapDebugImg(bmp.Index);
end.

E: Angle spread should be a little different though, I guess..

This one is capable of spreading amongst the whole incoming angle.

program new;
const
  w = 250; //Width
  h = 250; //Height
  amount = 750; //Amount of dots to draw
  SpreadFactor = 3; //Spread from the centre, higher = less spread
  IncomingAngle = 90; //Angle at which you approach the center, 0..360
  AngleSpread =8; //Spread from the incoming angle (whether it should concentrate around the incoming angle
                    //, -1 for complete random, higher = less spread
  AngleSpreadShift = 0; //Change this value to concentrate more of the spread on the 'incoming' side,
                        //or the outgoing side


var
  bmp : TMufasaBitmap;
  i : integer;
  Dist : extended;
  RandomNum : extended;
  cntrx,cntry : integer;
  pixels : TPointArray;
  angle : extended;
begin
  DisplayDebugImgWindow(w,h);
  bmp := TMufasaBitmap.create;
  bmp.SetSize(w,h);
  setlength(pixels,amount);
  cntrx := w/2;
  cntry := h/2;
  Writeln(IncomingAngle / 180.0);
  for i := 0 to amount-1 do
  begin
    if AngleSpread = -1 then
      angle := Random(9999) / 9999.0 * 2* pi //Angle between 0..2pi
    else
    begin
      //f(x) = 1/(1 + 2^(-c*x)); c = SpreadFactor; x must be in range [-1,1];
      RandomNum := Random(9999) / 9999.0 *2 - 1 + AngleSpreadShift; //Between -1 and 1
      angle := (1 / (1 + pow(2,-AngleSpread*RandomNum)))* pi; //Random number between 0..pi
      if random(2) =1 then
        Angle := IncomingAngle / 180.0 * pi+ Angle //Add the random angle to the incoming angle.
      else
        Angle := IncomingAngle / 180.0 * pi- Angle; //Add the random angle to the incoming angle.
    end;
    RandomNum := Random(9999) / 9999.0; //Between 0..1
    dist := (pow(randomnum,SpreadFactor));
    pixels[i] := point(Round(cos(angle) * dist * (cntrx-1) + cntrx), Round(-sin(angle) * dist * (cntry-1) + cntry));
  end;
  bmp.DrawTPA(pixels,clred);
  DrawBitmapDebugImg(bmp.Index);
end.

Very nice, use whichever version is the most efficient. The main reason I posted this thread was so more people can get an idea of what needs to be done and work on it :P.

From: i luffs yeww
>_> Well I wouldn't say this has anything to do with better autoing. To be honest there is no point to this at all. But whatever. I'll suggest these.

Actually, may I ask some actual uses for these? Apart from this single thing which is a waste of time, of course.

The use for Ln is obvious.

Erf(e) is the error function.

http://en.wikipedia.org/wiki/Error_function

I cant explain the immediate applications, but I have needed it many times before for various other gauss applications.


Also mastaraymond, later today I will get around to doing a distributed accuracy check on the clicks your script generates. It's very easy to to get confused on the outputted image. Sometimes it will simply distribute an even amount of clicks in each section, when it really isn't generating a Gauss distribution. Meaning, it will look as if there is more clicks towards the center point, but in reality it may be the same amount of clicks as the outer areas, just the clicks in the inner area are in a smaller region.

Though more than likely yours is accurate.

So can we talk about the need for this? I still don't understand why it is important. We should focus on not being reported, rather than having less noticeable mouse clicks if Jagex decides to pour over days worth of mouse clicks every account that gets reported.

Honestly though, the time that you've put into this function is probably more time than Jagex puts into monitoring mouse clicks. Not to put you down, it's a great function, it will probably get included if you can make it work reliably and fast.

But no misclicks. Your point (that I saw) was that reflection could find the proper tile if it walks away. No. We are not a reflection reliant community. We can do things without reflection, and we should not have to rely on it to fix the script if our mouse clicks always mess up.

So, I got permission for using the function, here is what I used:

{
  Written by Dr. Steven Beauchemin; Released to Nava2
  Calculates numbers within a Gaussian distribution of numbers about the mean
  with +/- the variance (aka. sigma).
}
function cal_normal_random(mean, sigma: Extended): Extended;
var
  r, r2, c1, c2, c3, c4, c5, gauss_rand: Extended;
  max, i: Integer;
begin
  max := 2147483647 ;
  r := 0.0;
  for i := 0 to 11 do
    r := r + (random(max)+1.0)/(max*1.0);

  c1 := 0.029899776 ;
  c2 := 0.008355968 ;
  c3 := 0.076542912 ;
  c4 := 0.252408784 ;
  c5 := 3.949846138 ;

  r := (r-6.0)/4.0 ;
  r2 := r*r ;
  gauss_rand:= ((((c1*r2+c2)*r2+c3)*r2+c4)*r2+c5)*r ;
  result := mean + sigma*gauss_rand;
end;

procedure Gauss_Point(cX, cY: Integer; maxRad: Integer; out oX, oY: Integer);
var
  angle: Extended;
  radius: Extended;
  xShift, yShift: Integer;
begin
  // random angle about the center;
  angle := random(360);

  radius := cal_normal_random(0,maxRad/2.0);

  if (Abs(radius) >= maxRad) then
  begin
    if (radius > 0) then
      radius := maxRad - 1
    else
      radius := (maxRad - 1) * -1;
  end;

  xShift := round(radius * Cos(angle));
  yShift := round(radius * Sin(angle));

  oX := cX + xShift;
  oY := cY + yShift;
end;

const
  TRIALS = 400;
var
  x, y, i, bmp, time, time2: Integer;
  tpa1, tpa2: array [0..TRIALS-1] of TPoint;
begin
  bmp := CreateBitmap(200, 100);

  time := GetSystemTime;
  for i := TRIALS-1 downto 0 do
  begin
    x := randomrange(10, 90);
    y := randomrange(10, 90);
    tpa1[i] := Point(x,y);
  end;
  time := GetSystemTime - time;

  //
  time2 := GetSystemTime;
  for i := TRIALS-1 downto 0 do
  begin
    Gauss_Point(150, 50, 40, x, y);
    tpa2[i] := Point(x,y);

  end;
  time2 := GetSystemTime - time2;

  writeln(format('SRL::   T: %dms Each: %fms', [time, time/(TRIALS * 1.0)]));
  writeln(format('Gauss:: T: %dms Each: %fms', [time2, time2/(TRIALS * 1.0)]));

  for i := 0 to TRIALS-1 do
  begin
    FastSetPixel(bmp, tpa1[i].x, tpa1[i].y, clGreen);
    FastSetPixel(bmp, tpa2[i].x, tpa2[i].y, clRed);
  end;

  DisplayDebugImgWindow(200, 100);
  DrawBitmapDebugImg(bmp);

  FreeBitmap(bmp);

end.

Very Nice Nava. Also nava to speed up the script I suggest moving the variable assignments out of the loop and at the start of the function.

These

c1 := 0.029899776 ;
c2 := 0.008355968 ;
c3 := 0.076542912 ;
c4 := 0.252408784 ;
c5 := 3.949846138 ;

Since there's no changing variables in them, theres not really a reason to have them in the loop as that would just slow down the script(not by any huge amount though)

From: 3Garrett3
So can we talk about the need for this? I still don't understand why it is important. We should focus on not being reported, rather than having less noticeable mouse clicks if Jagex decides to pour over days worth of mouse clicks every account that gets reported.

Honestly though, the time that you've put into this function is probably more time than Jagex puts into monitoring mouse clicks. Not to put you down, it's a great function, it will probably get included if you can make it work reliably and fast.

But no misclicks. Your point (that I saw) was that reflection could find the proper tile if it walks away. No. We are not a reflection reliant community. We can do things without reflection, and we should not have to rely on it to fix the script if our mouse clicks always mess up.

If you read the thread, the need for it has been stated multiple times. We know more than likely if you're not reported then you don't need to worry about getting banned. But if you are reported they can detect your clicks and see the accuracy. Aside from that the Anti-Macro system is supposedly always monitoring precision of clicks in the same area to see if its a human clicking or if its just landing anywhere in a random box like Function Mouse does.

The time that is getting put into developing these functions is minimal in comparison to how useful they will be when finished. The reflection part I stated was simply a potential fix. The missclicking part of the function can be optional obviously. Saying having to rely on it to fix the script if the mouse clicks always mess up… The potential for missclick would be based on SEVERAL factors… Mouse Distance from target point, approaching angle, approaching velocity. If missclicks are enabled, they would only be like 1/1000+ chance. So saying "always mess up" is an overstatement.

We should also focus on not being important but that doesn't mean we can't improve other aspects. We should have our functions and methods ahead of Jagex in terms of avoiding detection.

Misclicks are important in certain situations, which is why it will be option to turn on and there will be many factors determining if it will misclick.

If the meaning is still unclear to why we should develop something like this, then you should go back and reread the thread.

I can say that I am 6'7", yet I am only 6'1". You have no way of knowing otherwise, since you've no proof. Same applies here. They can say that they are monitoring every single person's screen every frame, but you've no proof that they do.

Again, as I always state in things like this, Jagex is a business. They do this to make money. If you're paying them, they don't give a shit how you play or how often you play or if you cheat once in awhile or whatever you do. As long as it doesn't cause others to not give them their money. kthxbai.

From: i luffs yeww
I can say that I am 6'7", yet I am only 6'1". You have no way of knowing otherwise, since you've no proof. Same applies here. They can say that they are monitoring every single person's screen every frame, but you've no proof that they do.

Again, as I always state in things like this, Jagex is a business. They do this to make money. If you're paying them, they don't give a shit how you play or how often you play or if you cheat once in awhile or whatever you do. As long as it doesn't cause others to not give them their money. kthxbai.

That doesn't matter if there's proof or not. There's probably suspicion to improve the functions.

I don't understand why there's so many people who oppose improving the functions. Improving them takes little time and is well worth it in the long run, EVEN IF they don't have a current detection system in place that can detect click accuracy. They would more than likely have it in the future.

It doesn't matter if what they say is true or not, improving the click generation will have no negative side effects on autoing. As you stated, the one thing that could mess it up is misclicking, which is obviously going to be optional.

I don't see what the big deal is with being against it. Some people actually like coding and coming up with better methods even if the need for the method is not immediate.

How many people play RS? If they have people who monitor a summation of hours of gameplay in a monotonous detail like mouse clicks vs radius vs misclicks, do you really think that they would dedicate it to the majority of people who are reported for bots? The first thing would be a log of your OVERALL gameplay. The first thing that we need to do is make sure our overall gameplay isn't detectable without getting into these little details. Endless loops, not solving randoms, misclicks tons of times, clicking the exact colour every time, no randomness in anything. These are the major things. I've never been banned with SRL (from what I can remember) in the last 3 years or however long I've been here. This obviously isn't a major deal.

Yes, you are doing something important, don't get me wrong. But this isn't the be-all end-all that you are making it out to be. This is a tiny little detail which has had a week of work put into it, which will maybe help one person out in the next year or two of autoing in SRL.

Solve a random, create a new and interesting method of antiban. Do the big things. Then focus on the perfection of little things.

There are more important things that you could be working on, for one. You're obviously smart enough to work on something more than just Gaussian math for a mouse function. It'd be much better for you to work on randoms or walking or anything that is currently not 100%. (M)Mouse work just fine. So far it seems as though these will add time to the autoing. That is not the point of autoing. If you wanted to improve the chance of not getting caught, work on randoms or walking or shit like that, not mouse functions that work just fine.

;D <3 you Garrett.

Seriously guys, can we all just get along and make this a kickass function? :) it does not matter if this is necessary or not - all I know is that this function is theorically better than what we already have, and in practice it could replace MouseBox without any delay. And no misclicks please - the benefits from including misclicks are slight-to-inexistent, but everytime a misclick happens you run the chance of a complete script fuckup.

From: 3Garrett3
How many people play RS? If they have people who monitor a summation of hours of gameplay in a monotonous detail like mouse clicks vs radius vs misclicks, do you really think that they would dedicate it to the majority of people who are reported for bots? The first thing would be a log of your OVERALL gameplay. The first thing that we need to do is make sure our overall gameplay isn't detectable without getting into these little details. Endless loops, not solving randoms, misclicks tons of times, clicking the exact colour every time, no randomness in anything. These are the major things. I've never been banned with SRL (from what I can remember) in the last 3 years or however long I've been here. This obviously isn't a major deal.

Yes, you are doing something important, don't get me wrong. But this isn't the be-all end-all that you are making it out to be. This is a tiny little detail which has had a week of work put into it, which will maybe help one person out in the next year or two of autoing in SRL.

Solve a random, create a new and interesting method of antiban. Do the big things. Then focus on the perfection of little things.

You misunderstand the macro detection system. It's not people monitoring. It's automatic. Of course they don't hire people to monitor players clicks, that would be unreasonable. It's not hard to create a function that takes the clicks and calculates the precision. I COULD make a script for that in a few minutes.

Of course certain things need work, but this is a LARGE community. Some pople want to do different things. If you want to work on walking on the minimap or on anti-randoms, then go work on it. No one is making any rule that says you must work on this or that. You can do what you want and contribute to the community.

From: i luffs yeww
There are more important things that you could be working on, for one. You're obviously smart enough to work on something more than just Gaussian math for a mouse function. It'd be much better for you to work on randoms or walking or anything that is currently not 100%. (M)Mouse work just fine. So far it seems as though these will add time to the autoing. That is not the point of autoing. If you wanted to improve the chance of not getting caught, work on randoms or walking or shit like that, not mouse functions that work just fine.

;D <3 you Garrett.

Of course there is 'more important' things, but I have no interest in working on them. No one is paying me and I am doing this on my own free will out of my own interest. I don't even play the game. As I just said a little bit up, anyone in the community can work on whichever they want and contribute. Things will be accomplished much more quickly if people work on different things at the same time. As for applying the Gaussian Math function elsewhere, I really see no other place it could be used in terms of scripting and autoing on runescape. Sure these details like precision are tiny, but jagex can easily make scripts that automatically flag your account if it is exhibiting abnormal clicks. I COULD make a script/function like that which would take up very little processing power.

From: Cigue
Seriously guys, can we all just get along and make this a kickass function? :) it does not matter if this is necessary or not - all I know is that this function is theorically better than what we already have, and in practice it could replace MouseBox without any delay. And no misclicks please - the benefits from including misclicks are slight-to-inexistent, but everytime a misclick happens you run the chance of a complete script fuckup.

As stated so many times already, the misclicking will be optional. Its very easy to set a boolean to enable/disable it.. I haven't even gotten around to incorporating angular offset based on the angle the mouse is approaching. Because I said it will be optional so many times, it confuses me to why people are so worried about it messing up scripts. It's making me think people are simply posting without reading what's been said in the thread already.

I think there has already been 3-5 different Gauss mouse functions posted on this thread, which is a good thing. And I will say it again, no one is forcing anyone to work on this. I have stated my reasons why I see it as important and if you disagree then you can go work on something else in SRL that needs more work. Nothing is ever perfect and almost all of it can be improved in some way or another.

Don't fix what isn't broken.

That is all.

From: i luffs yeww
Don't fix what isn't broken.

That is all.

That's a logical paradox. You can not fix something which isn't broken.

We are simply improving something which isn't perfect.

From: Xtensity
Very nice, use whichever version is the most efficient. The main reason I posted this thread was so more people can get an idea of what needs to be done and work on it :P.





The use for Ln is obvious.

Erf(e) is the error function.

http://en.wikipedia.org/wiki/Error_function

I cant explain the immediate applications, but I have needed it many times before for various other gauss applications.


Also mastaraymond, later today I will get around to doing a distributed accuracy check on the clicks your script generates. It's very easy to to get confused on the outputted image. Sometimes it will simply distribute an even amount of clicks in each section, when it really isn't generating a Gauss distribution. Meaning, it will look as if there is more clicks towards the center point, but in reality it may be the same amount of clicks as the outer areas, just the clicks in the inner area are in a smaller region.

Though more than likely yours is accurate.

It should be random enough, random num between 0..1 to a high power results in a kind-off distributed point-spread.

Also, I just used a Sigmoid function (instead of the Error function) fine replacement for this need.

From: mastaraymond
It should be random enough, random num between 0..1 to a high power results in a kind-off distributed point-spread.

Also, I just used a Sigmoid function (instead of the Error function) fine replacement for this need.

My other applications for the Error Function was also unrelated to autoing.

I'm no calculus expert. The reason I needed the error function is because one of the anti-derivatives of a certain function I had required the use of the Error Function.

I also forgot I made this while stoned the other day :P

Function Erf(x:Extended):Extended;
begin
result:=(2/Sqrt(Pi))* Exp( (-1)*Sqr(x) )
end;

It works the exact same as Erf. Though I shouldn't have to just recreate common math functions :P

What exactly is the error function?

From: Cigue
What exactly is the error function?

http://en.wikipedia.org/wiki/Error_function

Edit:

Basically how I applied it with the Normal 1Dimensional Gaussian Distribution function when I was testing out potetial methods for this script…

Function Cummulative(x,m,q:Extended):Extended;//Finds Percent for Normal Distribution
begin
result:=(Exp(sqr(m - x)/(2*sqr(q)))*q*Erf((m - x)/(Sqrt(2)*q)))/ (2*Sqrt(Exp(sqr(m - x)/sqr(q))*sqr(q)))
end;

q in the variable = standard deviation I think, and the m is the mean. Though I could be wrong since I coded this a week ago and haven't used it since.

Either way, all this is, is the Anti-Derivative of the Normal Distribution function.

I made this a week ago or so. (I think) it calculates the likelyhoodfor landing in area "X ± #Standard Deviation"… I'm not really sure since I don't need it anymore. Though I have a general idea of what it does if I played around with it a bit more. That's why I needed the error function. If I never need anything else like this in the future, chances are I will just recode it so I know fully what it's doing.

All that the error function is is a cumulative Gaussian curve.

Also, I don't have a loop in my function xten, merely one which calculates random numbers.

By the way, the gaussian function was written by a Doctor of comp sci/mathematics. :|

From: Nava2
All that the error function is is a cumulative Gaussian curve.

Also, I don't have a loop in my function xten, merely one which calculates random numbers.

By the way, the gaussian function was written by a Doctor of comp sci/mathematics. :|

I realized that lol. The one you posted is much more efficient than mine.

@3Garrett3 and i luffs yeww: If you still don't understand why this is a good idea, you should reread this post and read up on Gaussian distribution.

The goal is to simply "hit it." A human will still aim for the bullseye, to increase the chance of hitting the dartboard. Thus hits will be concentrated towards the bullseye, but there will still be hits nowhere close, and some misses too.
A macro does not have human flaws, and can always hit the dartboard. However, if randomized in the "area of uncertainty" there is no such pattern."

This will also raise the alarm. More advanced yet, some macros will actually form concentric regions of where the clicks will land. Still, we're always ahead of rulebreakers. Our final line of defense in this criteria is to analyze the regions most commonly clicked.

A macro tends to click in a perfect square, circle, or sometimes the shape of an interface icon. Sometimes even the region is randomized. Human behavior is not truly random however. The region most commonly clicked is related to placement, which is all I know about this.

MMouse is just too random to mimic human behaviour. I think the miss click is a bit too much, though.

It's a nice development, Xtensity! Keep it coming!

Question is wether a human clicks in the box on a "Gaussian-curve" way..

I think you can say that most of the clicks will indeed be close to the target and less will be further away. So normal distribution probably applies here, but there are numerous ways to apply them.

From: nielsie95
@3Garrett3 and i luffs yeww: If you still don't understand why this is a good idea, you should reread this post and read up on Gaussian distribution.



MMouse is just too random to mimic human behaviour. I think the miss click is a bit too much, though.

It's a nice development, Xtensity! Keep it coming!

Yeah misclick would be optional, if I get around to ever putting it in here.

I've already seen several scripts posted on this topic that are more efficient in terms of speed then mine and work off several different methods. So I'm not sure if I could make anything better since I've seen much better coding by other people :P.

There's several scripts on the thread that could be used for a MouseGauss, including one which uses some type of angular offset. The only thing needed to better incorporate that would be to make some kind of algorithm that deals with the approaching distance and angle…

I actually have an idea to incorporate the angular offset without inducing a misclick. It would simply do something along the lines of, if the distance is enough and the approaching angle is 270degrees(on the unit circle), then there is a higher chance of landing in the low percentage ranges on the opposite side of the circle. Meaning…depending on the approaching angle, the chances of landing in the 10% range on the approaching angle from a large distance will be the same as landing in the 90% range from a close distance.

I've been busy lately, so if anyone else wants to give that a shot then feel free. All that would need to be done is before generating the point to move to is the GetMousePos would gotten and the angle would need to be figured out between the current Mouse Pos and the target point. Then based off some distance it can be normalized in the 10%-100% range, so that the generated target point will have a greater chance of landing in a certain range..

I'm working on a method right now that favors lower percentile areas the further the mouse is from the target point. Maybe once I post it someone can try to incorporate it into their script if they don't already have a method for that.


edit: mastaraymond has a fairly good method for favoring the incoming angle, though when playing with his script I couldn't figure out how to adjust the circle radius to click in.

mastaraymond would you have an idea how to do that with your script?

http://villavu.com/forum/showpost.php?p=729838&postcount=66

From: i luffs yeww
Don't fix what isn't broken.

That is all.

Now, I'm pretty pissed you're just strutting into this thread and saying everything is useless and complaining over Xtensity. But I'll try to not let that shine through.

I think Xtensity has done a brilliant job getting us all to work on this and working himself on it. We now have 4-5 functions here to do the same, and nothing is more healthy than a good competition.

I do agree, missclicks are not a very useful application, but IT IS GOING TO BE OPTIONAL. It's been said 50 times, don't bring it up as an argument or I will personally carve it into your computer-screen.

Also, I come here and I don't want to program something that makes me need to play RS to do. I like looking working in theory and with math and simply playing around with the pieces until you have a clean function that does it's job.

Also, don't fix what isn't broken doesn't apply here. That would make the world a shitty place.

Just making myself clear, here.

(I haven't said one thing about mis-clicking by the way.)

I don't see the point in this because there are more important things to work on. I'm not complaining over Xtensity or anything, I'm actually complimenting him, in case you didn't notice. Mouse functions work just fine as they are. I simply see no reason to make such a big deal out of this. I don't care if you mess around with some math-related functions or anything. Go ahead. But should this be in SRL? Simba? No. Not now, anyway.

I'm actually surprised that this has got as much attention as it has. I brought up a way to "improve" (using the definition that seems quite constant in this thread; more "human-like" and "random") walking, which was shot down, as walking now works fine. I'm not trying to just whine about my idea not being pushed, because I truly don't care, but it's the only example I know of off the top of my head.

Also, randoms and color walking could be much more mathematical than this, imo. You already have the equations, so you just have to write them in Pascal. With randoms you can do a number of ways to solve them. Look at some past randoms and get some ideas. Same goes for color walking. LordGregGreg had some excellent color walking when he was around. Take a look at his stuff if you want.

I think that it's great that people are working together (what with MSI and this). I just would like to see work on more important things than this.

Bash/flame all you want, I'm done here.

(And I did read the thread. Every single word.)

Great work, Xten.

Human-like mouse movement and actions are always needed. Even thought current mouse functions are good, they are not perfect, I myself do not move my mouse like that. So, I appreciate everything Xtensity and everyone else involved are doing.

From: i luffs yeww
But should this be in SRL? Simba? No. Not now, anyway.

Why not? I think you just don't understand.. Humans don't click exactly at the same point every time, but they also don't click at a complete random point in a square. According to what's posted before, Jagex can detect this kind of behaviour (automatically). Sure, other things are important too, but that is not what this thread is about.

Frement: It is not about the movement of the mouse, it is about where it goes to (and clicks).

From: i luffs yeww
Just making myself clear, here.

(I haven't said one thing about mis-clicking by the way.)

I don't see the point in this because there are more important things to work on. I'm not complaining over Xtensity or anything, I'm actually complimenting him, in case you didn't notice. Mouse functions work just fine as they are. I simply see no reason to make such a big deal out of this. I don't care if you mess around with some math-related functions or anything. Go ahead. But should this be in SRL? Simba? No. Not now, anyway.

I'm actually surprised that this has got as much attention as it has. I brought up a way to "improve" (using the definition that seems quite constant in this thread; more "human-like" and "random") walking, which was shot down, as walking now works fine. I'm not trying to just whine about my idea not being pushed, because I truly don't care, but it's the only example I know of off the top of my head.

Also, randoms and color walking could be much more mathematical than this, imo. You already have the equations, so you just have to write them in Pascal. With randoms you can do a number of ways to solve them. Look at some past randoms and get some ideas. Same goes for color walking. LordGregGreg had some excellent color walking when he was around. Take a look at his stuff if you want.

I think that it's great that people are working together (what with MSI and this). I just would like to see work on more important things than this.

Bash/flame all you want, I'm done here.

(And I did read the thread. Every single word.)

Great work, Xten.

I saw your suggestion for improving walking, but we can work on MORE than 1 project at a time. Of course the mouse functions work but as stated before they could be improved for safety at little cost to the user when finished.

It's not like if they are in Simba/Srl that it will hurt the program… It's like 1 function.

If you have ideas for improving other functions then make a topic with your ideas and potential methods. I would help the best I could, just right now I can't think of any actually scripting improvements for walking or randoms(mainly because I've never really messed with any RS specific scripts other than my own Fletchers or alchers I've created… I've never messed with walkers or anti-randoms etc)

If you have ideas for improving ANYTHING you should post them in the development with potential methods. I figure when I see ways to improve I can find some kind of math to apply to them to make them more efficient.

Your idea was not shot down. Though your idea would not have taken over this thread either because this thread is for something other than Anti-Random or Walking improvements. The more active development threads there are about improvements, the more active the forums will be… resulting in faster advancement in various functions and methods, which is GOOD.

Honestly, everything we need to make a perfect MouseGauss function is already in the thread posted by multiple users… it's just a matter of selecting the best and most efficient features and putting them together in a function.

The same thing can go for various walking.. I figure if I think about map walking enough I can come up with ways to improvement. The only reason the clicking was on my mind is because I read the article that discussed the clicks. If ideas about map walking are on my mind then I am bound to come up with ideas to better develop mapwalking.

Go make a thread with your ideas for improvement like I did and I will go and try to come up with methods and I'm sure everyone else will also. You don't even need to post a script to go with it, if you read the thread you would see that the original function I posted was shitty in comparison to everyone elses. It's the Idea that matters.

See what I'm saying?

From: nielsie95
Why not? I think you just don't understand.. Humans don't click exactly at the same point every time, but they also don't click at a complete random point in a square. According to what's posted before, Jagex can detect this kind of behaviour (automatically). Sure, other things are important too, but that is not what this thread is about.

Frement: It is not about the movement of the mouse, it is about where it goes to (and clicks).

nielsie, better mouse movements could be improved, but we don't need to worry about that because CxGamer has already developed something like that which would be a nice addition to SRL. Cx based his mouse movements off a Gauss function also.

http://villavu.com/forum/showthread.php?t=58201

(also on a sort of unrelated note)

I'm not sure how long SRL's Mouse() holds down the click for. I can not measure this as my SRL has been messed up for a while and I haven't gotten around to fixing it since I don't play RS anymore and I haven't needed it.

I assume it would hold down the click for a random (30-60) ms… as the Normal ClickMouse barely simulates the click without holding it down for a short 30ms period as a real human would.. If mouse does not do this, than it should be implemented. I assume it would though because I would think (atleast I hope) this would have occured to SRL Developers.

From: nielsie95
Frement: It is not about the movement of the mouse, it is about where it goes to (and clicks).

Yeah I know that, but someone else was working on the movement also.

Xten, SRL's mouse click is in Mouse.scar.

I think its randomly between 30 and 60 as you stated.

This is supposed to be a distance tracking thingy. No clue if it's right, but if it somehow works I would assume that the waits need tweaking. Maybe someone who plays legit might be able to get something out of it. You could also add a few lines to InvMouse and record some data while autoing (in a different section/file).

program new;
{$i SRL/SRL.scar}

var
  x, y, Count, Dist, Avg, Counter: integer;
  Pt: TPoint;
begin
  SetUpSRL;
  Avg := StrToInt(ReadIni('Human','Avg',AppPath+'\Tracker.ini'));
  if Avg = -1 then
    Avg := 0;
  Count := StrToInt(ReadIni('Human','Count',AppPath+'\Tracker.ini'));
  if Count = -1 then
    Count := 0;
  repeat
    wait(50);
    if not loggedin then exit;
    if GetCurrentTab = tab_Inv then
    begin
      repeat
        if not loggedin then exit;
        if GetCurrentTab <> tab_Inv then
          break;
        wait(10);
        GetMousePos(x, y);
        if PointInBox(Point(x,y), MIBox) then
        begin
          repeat
            if not loggedin then exit;
            GetMousePos(x, y);
            if not PointInBox(Point(x,y), MIBox) then
              break;
            wait(5);
            if IsMouseButtonDown(1) then
            begin
              repeat
                if not loggedin then exit;
                if not IsMouseButtonDown(1) then
                begin
                  GetMousePos(x, y);
                  if CoordsToItem(x, y) = 0 then
                    break;
                  Pt := ItemCoords(CoordsToItem(x, y));
                  Dist:= Distance(x,y,pt.x,pt.y);
                  WriteINI('Human', IntToStr(Count), IntToStr(Dist), AppPath+'\Tracker.ini');
                  Avg := (Count*Avg+Dist)/(Count+1);
                  WriteINI('Human', 'Avg', IntToStr(Avg), AppPath+'\Tracker.ini');
                  Inc(Count);
                  WriteINI('Human', 'Count', IntToStr(Avg), AppPath+'\Tracker.ini');
                  Counter := StrToInt(ReadINI('HumanFreq', IntToStr(Dist), AppPath+'\Tracker.ini'));
                  if Counter = -1 then
                    Counter := 0;
                  WriteINI('HumanFreq', IntToStr(Dist), inttostr(Counter+1), AppPath+'\Tracker.ini');
                end;
              until isfkeydown(12);
            end;
          until isfkeydown(12);
        end;
      until isfkeydown(12);
    end;
  until IsFKeyDown(12);
end.

After a while you should be able to copy from the INI below HumanFreq into a spreadsheet (in OOo it's paste special, separated by '=') and graph a slope.

@ everyone flaming me or whatever;

What I was saying is this (nobody picked up on it in my post, nobody tried saying I was wrong which means they knew it was true):

SRL has garnered me 0 bans in my entire span of being here. Now, I'm not the biggest autoer, but I've had my share of 24 hour runs single character. If Mouse was really so terrible, or *improve-able* one might say, then why is this such an insignificant part? This thread has 1000000 times more response than any thread asking for help in things like antirandoms, antiban, things that are extremely significant to the banning or not banning of a person, yet we hear 2-3 complaints from different people about antirandoms not working, every single day.

Does this not piss you off? That we literally have 5 people who have made something that will maybe stop 1 person from being banned in the next year, while the SRL Antirandoms have remained unfinished (not all randoms are solve-able for us) for the last how many weeks/months? If we had 5 people working with this much effort on a reliable solver for 1 single random, I'm sure we'd have more results, and a higher satisfaction rate of tons of people.

From: 3Garrett3
@ everyone flaming me or whatever;

What I was saying is this (nobody picked up on it in my post, nobody tried saying I was wrong which means they knew it was true):

SRL has garnered me 0 bans in my entire span of being here. Now, I'm not the biggest autoer, but I've had my share of 24 hour runs single character. If Mouse was really so terrible, or *improve-able* one might say, then why is this such an insignificant part? This thread has 1000000 times more response than any thread asking for help in things like antirandoms, antiban, things that are extremely significant to the banning or not banning of a person, yet we hear 2-3 complaints from different people about antirandoms not working, every single day.

Does this not piss you off? That we literally have 5 people who have made something that will maybe stop 1 person from being banned in the next year, while the SRL Antirandoms have remained unfinished (not all randoms are solve-able for us) for the last how many weeks/months? If we had 5 people working with this much effort on a reliable solver for 1 single random, I'm sure we'd have more results, and a higher satisfaction rate of tons of people.

+1
Color is basically near undetectable anyways- you can run scripts for 10 hrs or more and not get banned.

From: 3Garrett3
@ everyone flaming me or whatever;

What I was saying is this (nobody picked up on it in my post, nobody tried saying I was wrong which means they knew it was true):

SRL has garnered me 0 bans in my entire span of being here. Now, I'm not the biggest autoer, but I've had my share of 24 hour runs single character. If Mouse was really so terrible, or *improve-able* one might say, then why is this such an insignificant part? This thread has 1000000 times more response than any thread asking for help in things like antirandoms, antiban, things that are extremely significant to the banning or not banning of a person, yet we hear 2-3 complaints from different people about antirandoms not working, every single day.

Does this not piss you off? That we literally have 5 people who have made something that will maybe stop 1 person from being banned in the next year, while the SRL Antirandoms have remained unfinished (not all randoms are solve-able for us) for the last how many weeks/months? If we had 5 people working with this much effort on a reliable solver for 1 single random, I'm sure we'd have more results, and a higher satisfaction rate of tons of people.

They would have more post if people would post potential methods to code in the script.

Saying anti-randoms are broken gives no ideas. The only reason this thread got so many post is because I posted that Gauss stuff.

Complaining that the other thread has less post isn't going to make the people get more ideas. I posted this same method asking a month ago and no one had any clue. When I posted the Gauss method everyone got ideas to work on it.

The other threads aren't being ignored for no reason lol.

When people make efforts others try to help and throw in their opinions, others are more willing to help and contribute.

To be honest, I would probably work on some antirandoms if I had accounts, and Simba on Linux (wine is miserable).

From: Nava2

To be honest, I would probably work on some antirandoms if I had accounts

That's pretty much the only problem. No one is willing to lend accounts for random development and a single person is only capable of so much.

I still haven't got a single EvilBob account besides my own.. :/

IDK about everyone else but the reason I'm paying more attention to this thread than the other threads over the years is that I haven't seen that quote from jagex before.

So any volunteers to suicide bot 2 players exactly the same besides randomness style and see which gets banned first? Or how about running a distance tracker while playing legit to see what human like really means?

I would suicide, for about 2 days in a row at max with 8 hr breaks in between. Just don't know what you mean by randomness style.

From: DeSnob
I would suicide, for about 2 days in a row at max with 8 hr breaks in between. Just don't know what you mean by randomness style.

Gaussian distribution vs the current distribution for random clicks in a box.

That could work but what if one gets reported and not the other? They need to be able to go without getting reported to see how long they can last before the system catches them.

I think it's better to just try an map the human behaviour.

From: 3Garrett3

SRL has garnered me 0 bans in my entire span of being here…
…
that will maybe stop 1 person from being banned in the next year…

Google "anecdotal evidence". I see how you think this applies to everybody and it may be logical. But it's probably not correct. I think loads of people get their accounts banned.

Also, as you mention in your post, why do we work on this instead of random-solver?
Xtensity gives a brilliant explanation. And as I said, I like doing something that doesn't require me to do lots of work in RS, like this. Randoms is not one of those things ;)

From: King of Knives
Google "anecdotal evidence". I see how you think this applies to everybody and it may be logical. But it's probably not correct. I think loads of people get their accounts banned.

Also, as you mention in your post, why do we work on this instead of random-solver?
Xtensity gives a brilliant explanation. And as I said, I like doing something that doesn't require me to do lots of work in RS, like this. Randoms is not one of those things ;)

My point was not about not playing rs lol. I was just pointing out that we can work on multiple things but ideas need to be initiated.

http://www.fileden.com/files/2009/5/10/2436551//Mouse benchmark.rar
If you guys want to perform tests on humans, this rar contains a bmp image and the script. Just run the script in SCAR and click as much as you want on the glowing icons. Missclicks count!
It will save your relative cords to a file output.txt, you may paste that to pastebin and post a link here.

With that, we can plot the best gauss function. ;)

From: CX gamer
http://www.fileden.com/files/2009/5/10/2436551//Mouse benchmark.rar
If you guys want to perform tests on humans, this rar contains a bmp image and the script. Just run the script in SCAR and click as much as you want on the glowing icons. Missclicks count!
It will save your relative cords to a file output.txt, you may paste that to pastebin and post a link here.

With that, we can plot the best gauss function. ;)

Do you have some sort of method/method of generating the 2D-Gauss formula?

Also there's some potential issues with this. If the icons are simply glowing and you're clicking it then it is not the same as normal human clicking. Clicking on the game has lots of pauses inbetween which can alter the muscle reflexes in the hand and the impulses in the brain, resulting in different click patterns depending on how they are generated. The only accurate way I see reliable function from points is to get those points from actual game play and not from clicking glowing icons :P.

Your method would work but it wouldn't be accurate in the sense of clicking icons as they change…. because you are constantly in the mind set of consciously clicking these icons. While in the game you are clicking when the need arises, so its not your main mindset.

Your script would be better off run during gameplay and using the same focuses around the gametabs.

Your script would work but I think it would be too accurate because that's what the human is aiming for when gathering the clicks. While ingame they're just playing the game.

I could use excel to plot it. But you are right. :(

I also think that different buttons it wouldn't look the same, like I think I try to click more in the center of items in my inventory, but not as much as tabs.
If you were to record actual runescape behaviour, then data collecting would be much slower, but more accutare.

If I added more glowing buttons, like inventory items, would it be better then?

From: CX gamer
I could use excel to plot it. But you are right. :(

I also think that different buttons it wouldn't look the same, like I think I try to click more in the center of items in my inventory, but not as much as tabs.
If you were to record actual runescape behaviour, then data collecting would be much slower, but more accutare.

If I added more glowing buttons, like inventory items, would it be better then?

I don't think it would help it, just because of the overall method and intention. In the script you are aiming towards clicking the buttons so your mindset doesn't change and all of your mouse movements are in the same general area.

It would be more accurate ingame but not as hard as you are thinking… How I think it is…..have several T-Boxes set up for main clicking regions like the inventory tabs. So if a click falls in a T-Box then the script can compare that click relative to the center of the T-Box(what the mind goes for).

That way, with your script it is just making the user aim to click in whichever box it highlights, while if you set up TBoxes and just played the game, it would sort out the clicks depending on which TBox they fall in and at the same time the user would not be distracted with the goal of actually clicking in the tbox, giving a more realistic accuracy.

The way the data could be stored is, the center of each Tbox would resemble 0,0. So say a click lands in the Tbox of the inventory tab. It would then get the coordinates of where the click landed, relative to the center of the T-Box…

So say the TBox center is 270,150 (random numbers I just made up)…. the click lands at 265,151. The coordinate which is stored(for the gauss list) would be (-5,1).

This way the Gauss formulua can be generated from the accuracy on multiple points or whatever. I think your script already has it like that somewhat like that, but it would be more accurate it done ingame during game play for 1-3 hours. Though the user should be playing the game without thinking about the script while its running and recording clicks.

If anyone wants to make a script based on the idea I just provided above then feel free to. I am very busy today, but more tired than anything and am about to lay down for a nap(possibly several hours lol). Just an idea thrown out there.

From: NCDS
That's pretty much the only problem. No one is willing to lend accounts for random development and a single person is only capable of so much.

I still haven't got a single EvilBob account besides my own.. :/

next time i get a random ill swing you a pm or contact you on msn.

From: Xtensity
I don't think it would help it, just because of the overall method and intention. In the script you are aiming towards clicking the buttons so your mindset doesn't change and all of your mouse movements are in the same general area.

It would be more accurate ingame but not as hard as you are thinking… How I think it is…..have several T-Boxes set up for main clicking regions like the inventory tabs. So if a click falls in a T-Box then the script can compare that click relative to the center of the T-Box(what the mind goes for).

That way, with your script it is just making the user aim to click in whichever box it highlights, while if you set up TBoxes and just played the game, it would sort out the clicks depending on which TBox they fall in and at the same time the user would not be distracted with the goal of actually clicking in the tbox, giving a more realistic accuracy.

The way the data could be stored is, the center of each Tbox would resemble 0,0. So say a click lands in the Tbox of the inventory tab. It would then get the coordinates of where the click landed, relative to the center of the T-Box…

So say the TBox center is 270,150 (random numbers I just made up)…. the click lands at 265,151. The coordinate which is stored(for the gauss list) would be (-5,1).

This way the Gauss formulua can be generated from the accuracy on multiple points or whatever. I think your script already has it like that somewhat like that, but it would be more accurate it done ingame during game play for 1-3 hours. Though the user should be playing the game without thinking about the script while its running and recording clicks.

If anyone wants to make a script based on the idea I just provided above then feel free to. I am very busy today, but more tired than anything and am about to lay down for a nap(possibly several hours lol). Just an idea thrown out there.

That's a fine idea. But I don't think 1-3 would be nearly enough to get decent results. I think you're looking at 20-30 hours. I myself don't click very often on those game tabs. When I get woodcutting on my main (non-bot), I don't think I clicked any tabs for periods over 5 hours (doing ivy). XD
Questing would be a good thing to do, as it creates a bit chaos, so the player would need to click everywhere a bit.

Saving it relative to the midpoint may not be such a good idea, since you'll shift half a pixel to the left. I'd rather have the relative position from the top left corner, but that may just be me being subborn.

On another note, I doubt of the options for the right click menu make a nice center gauss curve. I think it's more to the left, where the text it. That also needs to be tested. So detect every right click, setup Tboxes for every option and check the result.

Also, missclicks aren't measured, but that's another story.

EDIT: Forgot to say, there is a party in my town tonight. So if no one else volunteers by then, I'll make it tomorrow afternoon. :)

What do you mean when you say you'll shift half a pixel to the left? You lost me on that part? The whole point of the gaussian function is to measure the frequency of the offset of a point when trying to aim for a specific point. So it doesn't matter if the point are all over the screen, as long as you do the TargetPoint-HitPoint, or viseversa.

What do you mean it shifts half a pixel? Last time I checked with computing, you can't take up 'half' of a pixel :S?

From: Xtensity
I don't think it would help it, just because of the overall method and intention. In the script you are aiming towards clicking the buttons so your mindset doesn't change and all of your mouse movements are in the same general area.

It would be more accurate ingame but not as hard as you are thinking… How I think it is…..have several T-Boxes set up for main clicking regions like the inventory tabs. So if a click falls in a T-Box then the script can compare that click relative to the center of the T-Box(what the mind goes for).

That way, with your script it is just making the user aim to click in whichever box it highlights, while if you set up TBoxes and just played the game, it would sort out the clicks depending on which TBox they fall in and at the same time the user would not be distracted with the goal of actually clicking in the tbox, giving a more realistic accuracy.

The way the data could be stored is, the center of each Tbox would resemble 0,0. So say a click lands in the Tbox of the inventory tab. It would then get the coordinates of where the click landed, relative to the center of the T-Box…

So say the TBox center is 270,150 (random numbers I just made up)…. the click lands at 265,151. The coordinate which is stored(for the gauss list) would be (-5,1).

This way the Gauss formulua can be generated from the accuracy on multiple points or whatever. I think your script already has it like that somewhat like that, but it would be more accurate it done ingame during game play for 1-3 hours. Though the user should be playing the game without thinking about the script while its running and recording clicks.

If anyone wants to make a script based on the idea I just provided above then feel free to. I am very busy today, but more tired than anything and am about to lay down for a nap(possibly several hours lol). Just an idea thrown out there.

The script I posted the other day just does inventory items, so you should be able to get a good deal of data from herblore, fletching, firemaking, and other inventory related activities, but loops for tabs and stuff could be added.

This may help in recording and graphing mouse movements and graphing them. I haven't quite read over the entire thread, but I think this is similar to what you are looking for: http://iographica.com/

From: Esteban
This may help in recording and graphing mouse movements and graphing them. I haven't quite read over the entire thread, but I think this is similar to what you are looking for: http://iographica.com/

We don't need to graph them, we need to generate a 2D Gauss function from them :P… then we graph the function, but we need to generate a function from points first.

From: Xtensity
What do you mean it shifts half a pixel? Last time I checked with computing, you can't take up 'half' of a pixel :S?

Oh I'm sorry, I meant that the width of a tab is uneven, so the mid-point is something and a half, so unless making each var an extended, doubling the size, the top-left option would be equally good. It can plot a gauss function just as good.

Iographica is not the thing we're looking for. While you can see the overall mouse paths, and the most critical paths and such, but generating a gauss function for that, is a tad tricky.
Example image

From: CX gamer
Oh I'm sorry, I meant that the width of a tab is uneven, so the mid-point is something and a half, so unless making each var an extended, doubling the size, the top-left option would be equally good. It can plot a gauss function just as good.

Iographica is not the thing we're looking for. While you can see the overall mouse paths, and the most critical paths and such, but generating a gauss function for that, is a tad tricky.
Example image

The TBoxes don't need to be EXACTLY covering every pixel of the box, just the general area of each box/tab.

From: Xtensity
The TBoxes don't need to be EXACTLY covering every pixel of the box, just the general area of each box/tab.

I'm seeing good progress being made Xtensity, great job!

If anyone else wants to try to finish it off, that would be nice. I'm really busy lately with classes about to start and don't have much time to dedicate towards scripting. I can come help with ideas and stuff but I'm really busy still.

Great job! I really think that we need this kind of stuff in srl.

Also I have an idea on how we could implement this to srl without needing to change the parameters in mouse procedures.

The black box would be the original box that we currently use in our mouse procedures.

In the new version our clicks would always go inside the red ellipse.

This is pretty much how my algorithm would do it:
1: Calculate the middle point of the box
2: Generate random angle between 0 and 360 ( 360*rand )
3: Somehow count the distance from the middle point to the red ellipse in the picture with the generated angle.
4: Use the Gaussian distribution to randomly generate the distance we will be using. (Between 0 and the distance we got in step 3).
5: Calculate the x and y coordinate with the random angle and distance we already generated.
6: Click/Move mouse.

Good method. If someone who has the time could put all the functions together, we would have it working perfectly. I would do this but as I previously mentioned, I lack the time.

All the functions and methods required are in this thread, just someone who has time needs to wade through them and form them into an efficient clicking function. In combination With CX_Gamers mousemovement function, it would work exquisitely human like.

{
  Written by Dr. Steven Beauchemin; Released to Nava2
  Calculates numbers within a Gaussian distribution of numbers about the mean
  with +/- the variance (aka. sigma).
}
function cal_normal_random(mean, sigma: Extended): Extended;
var
  r, r2, c1, c2, c3, c4, c5, gauss_rand: Extended;
  maxnum, i: Integer;
begin
  maxnum := 2147483647 ;
  r := 0.0;
  for i := 0 to 11 do
    r := r + (random(maxnum)+1.0)/maxnum;

  c1 := 0.029899776 ;
  c2 := 0.008355968 ;
  c3 := 0.076542912 ;
  c4 := 0.252408784 ;
  c5 := 3.949846138 ;

  r := (r-6.0)/4.0 ;
  r2 := r*r ;
  gauss_rand:= ((((c1*r2+c2)*r2+c3)*r2+c4)*r2+c5)*r ;
  result := mean + sigma*gauss_rand;
end;

procedure Gauss_Point(cX, cY: Integer; maxRad: Integer; out oX, oY: Integer);
var
  angle: Extended;
  radius: Extended;
  xShift, yShift: Integer;
begin
  // random angle about the center;
  angle := random(360);

  repeat
    radius := cal_normal_random(0,maxRad/2.0);
  until (abs(radius) <= maxRad);

  xShift := round(radius * Cos(angle));
  yShift := round(radius * Sin(angle));

  oX := cX + xShift;
  oY := cY + yShift;
end;

procedure gMMouse(x, y: Integer; rMax: Integer);
var
  nX, nY: Integer;
begin
  Gauss_Point(x, y, rMax, nX, nY);

  MMouse(nX, nY, 0, 0);
end;

procedure gMouse(x, y: Integer; rMax: Integer; Left: Boolean);
var
  nX, nY: Integer;
begin
  Gauss_Point(x, y, rMax, nX, nY);

  Mouse(nX, nY, 0, 0, Left);
end;

This is what I am using.

Nava, your gauss function seems a tab artificial, though the way you use it is great. :D
Maybe this is much simpeler?
[PHP]RGauss(Ratio : extended; power : integer) : extended;
begin
result := (random(20000) - 10000) / 10000;
result := ratio * result + (1 - ratio) * pow(result, power);
end;[/PHP]antti mies, that's a good idea. Though the corners would never be clicked.
But if you'd make the circle bigger, to it intersects with the corners of the box, and filter the points that fall out of the box (or allow human missclicks), it would click in the corners. However, this is dangerous as in someone with extremely bad luck could run into an infinite loop.

From: Xtensity
All the functions and methods required are in this thread, just someone who has time needs to wade through them and form them into an efficient clicking function. In combination With CX_Gamers mousemovement function, it would work exquisitely human like.

The problem is that my function doesn't end in a precalculated point, but rather moves towards the midpoint of the box and ends when a pulse ends inside of the box. I have proven it to be gaussian distributed.
However, my function CAN NOT end in a single pixel, so it can't be used to check aubury's location and such. Also my function can only be used once atan comes to the stable simba release. :)

I'm doing pretty good progress with the function I'm making :)

Alright, I'm testing Nava's gauss function.

EDIT:
µ = 0, sigma = 5, 1 000 000 samples;
http://a.imageshack.us/img90/5992/gauss.png

The only difference between Nava's gauss and mine is the input. I will benchmark to see how CPU consuming each one is.

EDIT2:
Nava: 711 054 times in 1 minute
Mine: 3 675 586 times in 1 minute

However I need to add that my gauss function isn't a perfect one. But I think if I use a tangent function, it will be more perfect, but I'll have to see what it does with performance.

program New;

const
  DEBUGWIDTH = 500;
  DEBUGHEIGHT = 500;

function RandomAngle: Extended;
begin
  Result := random(360)+rand;
end;


{
GaussianEx(MaxValue: Extended): Extended;

Returns absolute standard gaussian value between 0 and maxvalue.
Changes of returning over:
1: 0.317311
2: 0.045500
3: 0.002700
4: 0.000063
5: 0.000001
[url]http://davidmlane.com/hyperstat/z_table.html[/url]

If result is over MaxValue it will generate a new value}
function GaussianEx(MaxValue: Extended): Extended;
begin
  repeat
    Result := sqrt(-2 * log10(rand)) * sin(2 * PI * rand);
  until(Abs(result) <= MaxValue);
end;

//Turns the value from GaussianEx into a different scale.
function Gaussian(MaxValue: Extended): Extended;
var
  G: Extended;
begin
  G := GaussianEx(3);
  G := G/3;
  Result := MaxValue*G;
end;

function GaussianPoint(x, y, MaxRadius: Extended): TPoint;
var
  Angle: Extended;
  Radius: Extended;
begin
  Angle := Radians(RandomAngle);
  Radius := Gaussian(MaxRadius);
  Result.x := Round(x + cos(Angle-Pi/2)*Radius);
  Result.y := Round(x +sin(Angle-Pi/2)*Radius);
end;


procedure DrawPoints(AmouthOfPoints, DebugW, DebugH: Integer);
var
  Index, Bitmap: Integer;
  Points: TPointArray;
begin
  for Index := 0 to AmouthOfPoints do
  begin
    SetLength(Points, Length(Points)+1);
    Points[Index] := GaussianPoint(DEBUGWIDTH/2, DEBUGHEIGHT/2, min(DEBUGHEIGHT, DEBUGWIDTH)/2);
  end;
  Bitmap := BitmapFromString(DEBUGWIDTH, DEBUGHEIGHT, '');
  for Index := 0 to High(Points) do
  begin
    FastSetPixel(bitmap, Points[Index].X, Points[Index].Y, 65280);
  end;
  GetBitmapCanvas(Bitmap);
  CopyCanvas(GetBitmapCanvas(Bitmap), GetDebugCanvas, 0, 0, DEBUGWIDTH, DEBUGHEIGHT, 0, 0, DEBUGWIDTH, DEBUGHEIGHT);
  DisplayDebugImgWindow(DEBUGWIDTH, DEBUGHEIGHT);
end;


begin
  DrawPoints(5000, DEBUGWIDTH, DEBUGHEIGHT);
end.

I will later try with the ellipse thing I posted before.

Looks great! I'll test it later.

Using tangent maybe isn't such a good idea. The edges go REALLY big too quickly, making it so that half of the values go out of bounds. So the function needs to be repeated some times. However though, this is a closer approximation of a gauss curve.
http://a.imageshack.us/img829/4352/gausstan.png
EDIT:
SCAR Code:
[LEFT]function RGaussTan(index, avg, max : integer) : extended;
begin
repeat
result := PI * (random(20000) - 10000) / 20000;
result := index * tan(result);
until (abs(result) < max);
result := avg + result;
end;
[/LEFT]

Benchmarking it right now.
EDIT3: Alright, it's NEARLY as fast as my other function. It scored 3 182 866 times in 1 minute.

EDIT2:
Ooh you're going to hate me, antti..
http://a.imageshack.us/img844/5456/gaussfail.png
Note that I multiplied it by 10 to make it wider.

It didn't look too bad in the picture but ill test a different method soon.

Btw CX gamer what tool/script you use for drawing those graphs?

I quickly made a script to simulate the function 1 000 000 times, save it to an array divided in classed of 1 unit wide, output it in a single line in the debug seperated by spaces, paste it into excel, using the data import tool and finally graphing it.

From: CX gamer
I quickly made a script to simulate the function 1 000 000 times, save it to an array divided in classed of 1 unit wide, output it in a single line in the debug seperated by spaces, paste it into excel, using the data import tool and finally graphing it.

I understand everything else but importing data to excel. I have excel but I never really used it :(

Edit woot I made it :P

[PHP]1409,3083,3324,3457,3919,4364,4682,5234,5725,6411,7091,8369,9404,10809,12458,14575,17468,20512,24790,30163,36582,44468,53682,62587,69903,72227,69856,62785,53453,44301,36686,29686,24650,20181,16960,14687,12534,10811,9459,8170,7342,6420,5910,5218,4804,4248,3739,3593,3345,3013,1454[/PHP]

• Copy this list
• Then past it into a cell of excel
• Click the past options button
• Use text-import wizard
• Next
• Tick 'comma'
• Finish

Ffs i tried a different algorithm and got this: http://img837.imageshack.us/img837/3702/srl3.jpg

I think Nava's or mine will do just fine. :p

From: CX gamer
I think Nava's or mine will do just fine. :p

Can I see your algorithm?

Besically one of these two, one uses the tangent function, the other uses uneven powers. The first one is most accurate, but a bit slower during runtime.

function RGaussTan(index, avg, max : integer) : extended;
begin
repeat
result := PI * (random(20000) - 10000) / 20000;
result := index * tan(result);
until (abs(result) < max);
result := avg + result;
end;

function RGauss(ratio : extended; power : integer) : extended;
begin
  Result := (Random(20000) - 10000) / 10000;
  Result := ratio * result + (1 - ratio) * pow(result, power);
end;

Try this:

program New;
var
  I, Value, phase, TimeMark: Integer;
  IA: TIntegerArray;
  U, V: Extended;

//Algorithm by Abramowitz and Stegun. Modded by antti mies.
function GaussianEx(MaxValue: Extended): Extended;
begin
  repeat
    if(Phase = 0) then
    begin
      U := (random(1000000001) + 1) / (1000000002);
      V := random(1000000001) / (1000000001);
      Result := sqrt(-2 * log10(U)) * sin(2 * PI * V);
    end else Result := sqrt(-2 * log10(U)) * cos(2 * PI * V);
    Phase := 1 - Phase;
  until(Abs(Result) <= MaxValue);
end;


function Gaussian(MaxValue, MaxGaussian: Extended): Extended;
begin
  Result := MaxValue*(GaussianEx(MaxGaussian)/MaxGaussian);
end;



begin
  SetLength(IA, 51);
  ClearDebug;
  TimeMark := GetTimeRunning;
  for I := 0 to 1000000 do
  begin
    Value := Round( Gaussian(25, 2.5) )+25;
    Inc(IA[IAbs(Value)]);
  end;
  WriteLn('Took '+IntToStr(GetTimeRunning-TimeMark)+' milliseconds'+Chr(10)+Chr(10));
  for I := 0 to 50 do
    WriteLn(IntToStr(IA[I]));
end.

Edit: http://img837.imageshack.us/img837/1194/srl4.jpg

Took 32386 milliseconds


5
4
13
25
44
105
197
319
606
1076
1793
2830
4365
6755
9802
13879
18983
25058
32324
40095
47972
55876
62796
68002
71305
72525
70917
67609
62488
55983
48026
39958
32221
25083
19070
13784
9960
6878
4319
2893
1693
1052
567
374
201
93
41
17
12
5
3
Successfully executed (32464 ms)

Whoa that's the best one I've seen! :o

I'll post my own testing script, they look a lot alike.

program New;
var
  s : string;
  i, r, t : integer;
  a : array of integer;
  e : extended;

function RGauss(index, avg, max : integer) : extended;
begin
  repeat
    result := PI * (random(20000) - 10000) / 20000;
    result := index * tan(result);
  until (abs(result) < max);
  result := avg + result;
end;

begin
  clearDebug;
  setArrayLength(a, 51);
  for i := 0 to 50 do
    a [i] := 0;
  t := getTickCount;
  for i := 0 to 1000000 do
  begin
    r := round(RGauss(5, 0, 25)) + 25;
    a[r] := a[r] + 1;
    if (getTickCount - t) > 500 then
    begin
      status(intToStr(round(i / 10000)));
      t := getTickCount;
    end;
  end;
  for i := 0 to 50 do
  begin
    s := intToStr(a[i]) + ',';
    setLength(s, length(s) + 1);
    writeln(s);
  end;
  writeln('');
end.

I have been doing this for the whole day.. Atleast I found a working algorithm, got it transformed into pascal and learned how to use Microsoft excel :)

Edit: Reworked it a little bit and fixed a bug in it.

program New;

Const
  Width = 25; // Adjust the scale
  GaussianLimit = 3; // Adjust the slope. The higher the steeper.
  Instances = 1000000;  //How many results we want to test with?


var
  I, Value, phase, TimeMark: Integer;
  IA: TIntegerArray;
  U, V: Extended;

//Algorithm by Abramowitz and Stegun. Modded by antti mies.
function GaussianEx(MaxValue: Extended): Extended;
begin
  repeat
    if(Phase = 0) then
    begin
      U := (random(1000000001) + 1) / (1000000002);
      V := random(1000000001) / (1000000001);
      Result := sqrt(-2 * log10(U)) * sin(2 * PI * V);
    end else Result := sqrt(-2 * log10(U)) * cos(2 * PI * V);
    Phase := 1 - Phase;
  until(Abs(Result) <= MaxValue);
end;


function Gaussian(MaxValue, MaxGaussian: Extended): Extended;
begin
  Result := MaxValue*(GaussianEx(MaxGaussian)/MaxGaussian);
end;



begin
  SetLength(IA, Width*2+1);
  ClearDebug;
  TimeMark := GetTimeRunning;
  for I := 0 to Instances do
  begin
    Value := Round( Gaussian(Width, GaussianLimit) )+Width;
    Inc(IA[IAbs(Value)]);
  end;
  WriteLn('Took '+IntToStr(GetTimeRunning-TimeMark)+' milliseconds'+Chr(10)+Chr(10));
  for I := 0 to Width*2 do
    WriteLn(IntToStr(IA[I]));
end.

This development is great! I'm very happy that everyone is contributing.

I know that mine works, as those large numbers are actually parts of e^(ax^2+bx+c).

Anywho, I'm going to keep watching this, I don't fully understand the math, but I love this concept.

Your script looks great! I've benchmarked it and it did 2 431 221 times in 1 minute. Meaning that it's slower than mine, yet still WAY faster than Nava's. (Poor Nava :( )
Still, yours is more accurate, so I'd vote for your gaussian. :D

I'll try to graph it without excel.

I just realized that my algorithm uses the Box_Muller_Transform method that I used in the my first algorithm too. (I had typed lnxp1 instead of log10 so it didn't work properly)

That would just be a scale difference, but wouldn't change the overal shape. :P
Also, do you expect people to use GaussianEx seperately? Otherwise you could combine those functions into one. :P
And also, make those variables local, but you already knew that. :P

Great job.

From: CX gamer
That would just be a scale difference, but wouldn't change the overal shape. :P
Also, do you expect people to use GaussianEx seperately? Otherwise you could combine those functions into one. :P
And also, make those variables local, but you already knew that. :P

Great job.

Yes we could put them together.

U, V and phase cannot be local in my last function because the algorithm saves a little time when generating a lot of values. However we would only have to generate one value for the mouse function so I would prefer this:

//Uses the Box–Muller transform method to generate standard normally distributed random numbers.
function GaussianValue(MaxValue: Extended; Positive: Boolean): Extended;
var
  r1, r2: extended;
begin
  repeat
    r1 := (Random(2147483645) + 1) / 2147483646;
    r2 := Random(2147483646) / 2147483647;
    case Positive of
      True: Result := Abs(sqrt(-2 * log10(r1)) * sin(2 * PI * r2));
      False: Result := sqrt(-2 * log10(r1)) * sin(2 * PI * r2);
    end;
  until(Abs(result) <= MaxValue);
end;

And we can remove the positive boolean from this and always result positive…

I'm also doing good progress with my ellipse project :P

I'd keep the positive bool.

You could rewrite

    case Positive of
  True: Result := Abs(sqrt(-2 * log10(r1)) * sin(2 * PI * r2));
  False: Result := sqrt(-2 * log10(r1)) * sin(2 * PI * r2);
end;

As

Result := sqrt(-2 * log10(r1)) * sin(2 * PI * r2);
if positive then Result := Abs(Result);

=)

Edit:
Here is the script you can use to test:

program Gaussian;


Const
  GaussianLimit = 1.5;
  PointsToDraw = 3000;
  DEBUGW = 500;
  DEBUGH = 500;
  Ox1 = 50; //Box x1
  Oy1 = 100; //Box y1
  Ox2 = 200; //Box x2
  Oy2 = 470; //Box y2

//Returns a random angle in radians. (0 to 2*Pi)
function RandomAngle: Extended;
begin
  Result := 2*PI*rand;
end;

//Uses the Box–Muller transform method to generate standard normally distributed random numbers.
function GaussianValue(MaxValue: Extended; Positive: Boolean): Extended;
var
  r1, r2: extended;
begin
  repeat
    r1 := (Random(2147483645) + 1) / 2147483646;
    r2 := Random(2147483646) / 2147483647;
    case Positive of
      True: Result := Abs(sqrt(-2 * log10(r1)) * sin(2 * PI * r2));
      False: Result := sqrt(-2 * log10(r1)) * sin(2 * PI * r2);
    end;
  until(Abs(result) <= MaxValue);
end;

//Determines the gaussian value to a scale 0 - MaxValue
function Gaussian(MaxValue, MaxGaussian: Extended): Extended;
begin
  Result := MaxValue*(GaussianValue(MaxGaussian, True)/MaxGaussian);
end;


{Results the offsets from the middle of the biggest ellipse that can be drawn in the square x1, y1, x2, y2
with the given angle.}
function EllipseOffset(x1, y1, x2, y2: Integer; Angle: Extended): TPoint;
var
  A, B: Extended;
begin
  A := (x2-x1)/2;
  B := (y2-y1)/2;
  Result.x := Round(A*cos((Angle)));
  Result.y := Round(B*sin((Angle)));
end;


//Results the points for drawing the box and an ellipse inside it
function EllipsePoints(x1, y1, x2, y2: Extended): TPointArray;
var
  I: Integer;
begin
  for I := 0 to 719 do
  begin
    SetLength(Result, I+1);
    Result[I] := EllipseOffSet(Round(x1), Round(y1), Round(x2), Round(y2), Radians(I/2));
    IncEx(Result[I].X, Round(x1+x2)/2);
    IncEx(Result[I].Y, Round(y1+y2)/2);
  end;
  for I := 0 to Round(x2-x1) do
  begin
    SetLength(Result, Length(Result)+2);
    Result[High(Result)-1] := IntToPoint(Round(x1)+I, Round(y1));
    Result[High(Result)] := IntToPoint(Round(x1)+I, Round(y2));
  end;
  for I := 0 to Round(y2-y1) do
  begin
    SetLength(Result, Length(Result)+2);
    Result[High(Result)-1] := IntToPoint(Round(x1), Round(y1)+I);
    Result[High(Result)] := IntToPoint(Round(x2), Round(y1)+I);
  end;
end;



procedure DrawPoints(TPA: TPointArray; DebugW, DebugH: Integer);
var
  Index, Bitmap: Integer;
begin
  Bitmap := BitmapFromString(DebugW, DebugH, '');
  for Index := 0 to High(TPA) do
  begin
    FastSetPixel(bitmap, TPA[Index].X, TPA[Index].Y, 65280);
  end;
  GetBitmapCanvas(Bitmap);
  DisplayDebugImgWindow(DebugW, DebugH);
  CopyCanvas(GetBitmapCanvas(Bitmap), GetDebugCanvas, 0, 0, DebugW, DebugH, 0, 0, DebugW, DebugH);
end;


function GaussianPoint(x1, y1, x2, y2: Integer): TPoint;
var
  Angle: Extended;
  Ep: TPoint;
  AAA: Extended;
begin
  Angle := RandomAngle;
  EP := EllipseOffset(x1, y1, x2, y2, Angle);
  AAA := Gaussian(1,  Abs(GaussianLimit));
  Result.x := Round((x1+x2)/2 + {cos(Angle)*}EP.X*AAA);
  Result.y := Round((y1+y2)/2 + {sin(Angle)*}EP.Y*AAA);

  //  Result.x := Round((x1+x2)/2+A*cos((Angle-2*Pi)));
  //  Result.y := Round((y1+y2)/2+B*sin((Angle-2*Pi)));
end;


function GeneratePoints(AmouthOfPoints, DebugW, DebugH: Integer): TPointArray;
var
  Index: Integer;
begin
  for Index := 0 to AmouthOfPoints do
  begin
    SetLength(Result, Length(Result)+1);
    Result[Index] := GaussianPoint(ox1, oy1, ox2, oy2);
  end;
end;


begin
  DrawPoints(CombineTPA(GeneratePoints(PointsToDraw, DebugW, DebugH), EllipsePoints(Ox1, Oy1, Ox2, Oy2)), DebugW, DebugH);
  //DrawPoints(GeneratePoints(PointsToDraw, DebugW, DebugH), DebugW, DebugH);
  //DrawPoints(EllipsePoints(Ox1, Oy1, Ox2, Oy2), DebugW, DebugH);
end.

And here is the script you can use with your mouse procedures:

program Gaussian;


function Gaussian(MaxValue, MaxGaussian: Extended): Extended;
var
  r1, r2: extended;
begin
  repeat
    r1 := (Random(2147483645) + 1) / 2147483646;
    r2 := Random(2147483646) / 2147483647;
    Result := Abs(sqrt(-2 * log10(r1)) * sin(2 * PI * r2));
  until(result <= MaxGaussian);
  Result := MaxValue*(Result/MaxGaussian);
end;

function GaussianPoint(x1, y1, x2, y2: Integer): TPoint;
var
  Ep: TPoint;
  A, B, RandomAngle, GaussRand: Extended;
begin
  RandomAngle := 2*PI*rand;//Random angle in radians
  A := (x2-x1)/2;//X Radius for the ellipse
  B := (y2-y1)/2;//Y Radius for the ellipse
  EP.X := Round(A*cos(RandomAngle));//Max offset from the middle of the ellipse for X
  EP.Y := Round(B*sin(RandomAngle));//Max offset from the middle of the ellipse for Y
  
  GaussRand := Gaussian(1,  1.5);//Generate Random Gaussian value ]0, 1]
  Result.x := Round((x1+x2)/2 + EP.X*GaussRand);
  Result.y := Round((y1+y2)/2 + EP.Y*GaussRand);
end;


procedure GM(x, y, rx, ry: Integer);
var
  P: TPoint;
begin
  P := GaussianPoint(x, y, x+rx, y+ry);
  ClickMouse(P.X, P.Y, True);
end;


begin
{  repeat
  GM(100, 100, 400, 200);
  wait(5);
  until(false);}
end.

I tested the last script in paint:

One thing that is really confusing me.. sin/cos use Degrees.. you use Radians. Looks brilliant though.

From: Nava2
One thing that is really confusing me.. sin/cos use Degrees.. you use Radians. Looks brilliant though.

Do they?
I went to mapwalk.scar and I found this kind of stuff:

    MFNF(Trunc(Rad * Sin(Radians(FixD(Rs_GetCompassAngleDegrees + Deg))) + MMCX + Random(5)),
      Trunc(-Rad * Cos(Radians(FixD(Rs_GetCompassAngleDegrees + Deg))) + MMCY + Random(5)), 1, 1);

I guess I am incorrect! :)

Antti, great script! But could you expand the circle area more to cover the entire box, and make it calculate the points untill it's inside the box?

program NavaGotPwnt;
begin
  Writeln('antti mies > Nava2 := ' + BoolToStr(1 = (Sin(PI / 2))));
end

From: CX gamer
Antti, great script! But could you expand the circle area more to cover the entire box, and make it calculate the points untill it's inside the box?

program NavaGotPwnt;
begin
  Writeln('antti mies > Nava2 := ' + BoolToStr(1 = (Sin(PI / 2))));
end

I like the ellipse inside the box version more human like but I guess I can do that.

I think humans can still click corners.
Your paint example makes it a bit clear that it's clicking in an ellipse;
A human can still missclick, but it'll be filtered out.

You're doing great. :D

Wouldn't it make sense to actually see where humans click by page 7?

I think CX gamer is right.

From: CX gamer
antti mies, that's a good idea. Though the corners would never be clicked.
But if you'd make the circle bigger, to it intersects with the corners of the box, and filter the points that fall out of the box (or allow human missclicks), it would click in the corners. However, this is dangerous as in someone with extremely bad luck could run into an infinite loop.

I'm really starting to like this idea more and more :)

And I think we should also track human clicks. For example with clicking the game tabs as I think someone already mentioned in this thread. And we would need a lot of results too.

This is genious! By the way, about that post of the new macro detection system was it posted in the Runescape forums?

I think so, but they quickly removed it.

From: Deathscytex
This is genious! By the way, about that post of the new macro detection system was it posted in the Runescape forums?

http://rs-hacking.com/resources/macroingdetection.pdf

What happened to this? Is this project abandoned?

From: Zyt3x
http://rs-hacking.com/resources/macroingdetection.pdf

What happened to this? Is this project abandoned?

I hope not :(

With reflection, you'd be able to allow for misclicks and be able to realign yourself or resume wherever you were without problems.

I certainly vote that we try and get this project back, cause to me it seems like a good idea..

Why give your processor such a hard time for such a simple function, like really.

Unless you think jagex will calculate click points, and the boundaries of the said points, it's really unnecessary. Which without a doubt it is.

Instead, what you should of done is figured out a more human-like mouse move function, because that's something they could actually and realistically monitor, as a human moves the mouse much differently than all the current move-mouse function.

But even than, even the latter said proposition is quite superfluous, as jagex like any other company wouldn't waste their resources and server load on something so trivial.

How about creating some type of walking mechanism where the bot will be able to pan the camera around (as a player would), and multi-thread it into various other functions that would be used. Now I'm not telling you by any means to create this, as it's simply an example.

This said example works because:

Realistically, jagex will only have to store one boolean value per login-session to see if the character panned the camera around, and there are many other misc. things such as this that could potentially put a character into a red-flag zone, which would make the server/client more in-depth analysis of all the given input through the client.


By no means am I trying to offend you, I'm simply pointing out that your time could have been invested into something much more valuable toward the community. And don't take it the wrong way, I love people who contribute, but some things are just redundant if not completely unnecessary.

EDIT: Didn't even look at the PDF before I wrote this by the way, but found it to be funny as I thought of the camera example in less than a second and explained it in detail, and found it to be in the PDF.

http://rs-hacking.com/resources/macroingdetection.pdf

Too lazy to read what you said, but I think that .pdf should explain some stuff.

From: i luffs yeww
http://rs-hacking.com/resources/macroingdetection.pdf

Too lazy to read what you said, but I think that .pdf should explain some stuff.

http://villavu.com/forum/showpost.php?p=743217&postcount=163

Didn't click your link or read what you said, but that link should explain some stuff.

I read what you said, and I said the same exact things about it throughout this (and another, similar) thread. However, it seems as though they could be changing their methods. I think this is a valid idea. The dartboard example makes perfect sense, to me. Easy enough to monitor too. (Note that the ease of detection has nothing to do with it; they are a business and if people complain about bots (they do), they will want to get rid of them.)

I don't think this is needed RIGHT now, but I don't see why to not go through with it. I'd much rather have it implemented before they update their detection methods (if they do), so we're ahead of the game.

From: Feroc1ty

Unless you think jagex will calculate click points, and the boundaries of the said points, it's really unnecessary. Which without a doubt it is.

Instead, what you should of done is figured out a more human-like mouse move function, because that's something they could actually and realistically monitor, as a human moves the mouse much differently than all the current move-mouse function.

But even than, even the latter said proposition is quite superfluous, as jagex like any other company wouldn't waste their resources and server load on something so trivial.

Actually, it is an absolute KNOWN FACT that Jagex does record mouse movements on the client and sends them to the server. They have been doing this for years, since at least as far back as the 317 client (2005). If you would like I could show you the code in the client that handles this, or preferably you could just believe me.

Of course what they do with this data once it gets to the server is anyones guess, but I doubt they just throw it away.

^ I'd like to see, just to see. :) I'm interested in it. Thanks, if you do show me.

From: moparisthebest
Actually, it is an absolute KNOWN FACT that Jagex does record mouse movements on the client and sends them to the server. They have been doing this for years, since at least as far back as the 317 client (2005). If you would like I could show you the code in the client that handles this, or preferably you could just believe me.

Of course what they do with this data once it gets to the server is anyones guess, but I doubt they just throw it away.

And I specifically mentioned that it's a possibility that they record mouse movements, but if you think with logic and reason, you might see this:

-> Thousands of users
-> Each user might have a different computer
–> Client might lag for some, and be clean for others.
-> Theres thousands of different computer mouse products on the market
–> For most part each different mouse has different DPI and reaction time
-> Each user has different and unique style of moving the mouse
-> Each user has different reaction time
-> There's plenty of more examples but really no reason into getting farther into them.

Now… What all this information leads to? It means that all the mouse information they record wouldn't give them NEARLY enough evidence to declare someone a bot/autoer, as long as the program they are using doesn't instantly jump from point to point with no wait-time.

On the other hands, smaller and more trivial things such as locked camera angles (real players ALWAYS pan camera around), can all add up to be evidence.

Them checking to see how accurate a clients clicks would be completely irrational and a burden with really no actual evidence. Now, don't jump to conclusions, this doesn't say that they record mouse clicks, but rather how accurate the mouse clicks are, which is the original reason for this post. They would have to record the boundaries of clicked object, the position clicked, and they would have to do it to thousands of clicks. After all the data is recorded it's still completely useless, they would have to proccess it which would waste extra time and resources on their part… That's just not reasonable as the results really wouldn't give them any authentic evidence.

Now I'm not saying that the move-mouse function doesn't matter and we should completely ditch it and other human-emulating functions, but what I'm saying is that there's no point in investing all of your time into creating a computer to be as human as possible. As long as it doesn't act as a robot, it's fine. You're a programmer, you should know that when you want to create a dog class you don't recreate it complete, only the parts which are essential in your program.

Rather, after you are done with the function and it works fine, invest the time to create functions which create an over-all more human like behavior. A bot which moves the mouse completely like a human and does nothing besides that is useless.

From: Feroc1ty

-> Thousands of users
-> Each user might have a different computer
–> Client might lag for some, and be clean for others.
-> Theres thousands of different computer mouse products on the market
–> For most part each different mouse has different DPI and reaction time
-> Each user has different and unique style of moving the mouse
-> Each user has different reaction time
-> There's plenty of more examples but really no reason into getting farther into them.

Looks like a situation begging for the application of a learning based artificial intelligence system. Take twenty employees and mark 1000 players as bot or legit by hand, then feed it into a learning algorithm.

From: Smartzkid
Looks like a situation begging for the application of a learning based artificial intelligence system. Take twenty employees and mark 1000 players as bot or legit by hand, then feed it into a learning algorithm.

There's also different scripts and different bots, but it's a good idea… There's a reason I made custom includes for functions such as TypeText and MoveMouse etc…

And it's not because I don't enjoy includes that SRL community makes, it's simply because theres hundreds if not thousands of users that will move the mouse exactly the same.

I'm having trouble getting this script to work. I converted it to Simba;

Program GMous;
{$i srl/srl.scar}

Procedure RadialClick(x1,y1,R:Integer);
var xc, yc, xo, yo, oy, ox, BoxBounds, iR, iR2, c, xoff, yoff : Integer;
    z : Extended;
begin
  ox:=R  //X Radius
  oy:=R  //Y Radius
  xo:=x1   //X Center for accuracy Basis
  yo:=y1   //Y Center for accuracy Basis
  BoxBounds:=ox+ox;
  //This additional plus to get points of <30% accuracy.
  //Box Variable is to prevent point scanning outside of potential circle
  //iR:=RandomRange(RandomRange(Random(100),100),100)
  {This randomization you see above^, is an alternative to the one below
  The one above is much more accurate. I have not measured the difference
  between the two, but the way I designed it to work, the one above is much
  more accurate. Personally I would use the bottom one
  }
  iR := RandomRange(Random(100),100)
  for xc:= -BoxBounds + x1 to BoxBounds + x1 do
  begin
    for yc:= -BoxBounds + y1 to BoxBounds + y1 do
    begin
      begin
        z := (100 * Pow(2.71,(-1*((sqr(xc-xo)/(2*sqr(ox))) + (sqr(yc-yo)/(2*sqr(oy))))))); // Changed Exp To Pow and set the base as Euler's number
        if ((trunc(z) = Ir)) then
        begin
          iR2 := Random(3);
          if c >= IR2+1 then
          begin
            xoff:=(x1-xc);
            yoff:=(y1-yc);
            Case random(2) of
              0:xoff:=xoff;
              1:xoff:=-xoff;
            end;
            Case random(2) of
              0:yoff:=yoff;
              1:yoff:=-yoff;
            end;
            Case random(2) of
              {CHANGE CLICK MOUSE TO WHATEVER CLICKING FUNCTION YOU WANT,
              MOUSE,MMOUSE. i USED CLICKMOUSE FOR SIMPLICITY OF TESTING CLICKS
              IN PAINT.}
              0: Mouse(x1+xoff, y1+yoff, 0, 0, true);
              1: Mouse(x1+yoff, y1+xoff, 0, 0, true);
              { The reason I have this in a case is to randomly invert the offsets
              What this does is maintain the accuracy of the original offset
              while creating even larger variation.}
            end;
          end;
          Inc(c);
        end;
      end;
    end;
  end;
end;

begin
  SetupSRL;
  repeat
    RadialClick (185, 187, 30); // My paintbrush
    wait (1000); // Ignores this...?
  until (false)
end.

Currently it just makes a defined circle really nicely at radius R, then hops to a new circle. At the end of it, I saw more or less what looked like a dart board, or rather circles inside of each other getting smaller, like O's perfectly inside of an O.

Hey I decided to work on this again.

Converted my gaussian testing script to simba. (It draws stuff to debug box)

program Gaussian;


Const
  GaussianLimit = 1.7;
  PointsToDraw = 10000;
  DEBUGW = 700;
  DEBUGH = 700;
  Ox1 = 100; //Box x1
  Oy1 = 200; //Box y1
  Ox2 = 600; //Box x2
  Oy2 = 400; //Box y2

//Returns a random angle in radians. (0 to 2*Pi)
function RandomAngle: Extended;
begin
  Result := 2*PI*RandomE;
end;

//Uses the Box–Muller transform method to generate standard normally distributed random numbers.
function GaussianValue(MaxValue: Extended; Positive: Boolean): Extended;
var
  r1, r2: extended;
begin
  repeat
    r1 := (Random(2147483645) + 1) / 2147483646.0;
    r2 := Random(2147483646) / 2147483647.0;
    case Positive of
      True: Result := Abs(sqrt(-2 * log10(r1)) * sin(2 * PI * r2));
      False: Result := sqrt(-2 * log10(r1)) * sin(2 * PI * r2);
    end;
  until(Abs(result) <= MaxValue);
end;

//Determines the gaussian value to a scale 0 - MaxValue
function Gaussian(MaxValue, MaxGaussian: Extended): Extended;
begin
  Result := MaxValue*(GaussianValue(MaxGaussian, True)/MaxGaussian);
end;


{Results the offsets from the middle of the biggest ellipse that can be drawn in the square x1, y1, x2, y2
with the given angle.}
function EllipseOffset(x1, y1, x2, y2: Integer; Angle: Extended): TPoint;
var
  A, B: Extended;
begin
  A := (x2-x1)/2;
  B := (y2-y1)/2;
  Result.x := Round(A*cos((Angle)));
  Result.y := Round(B*sin((Angle)));
end;


//Results the points for drawing the box and an ellipse inside it
function EllipsePoints(x1, y1, x2, y2: Extended): TPointArray;
var
  I: Integer;
begin
  for I := 0 to 720 do
  begin
    SetLength(Result, I+1);
    Result[I] := EllipseOffSet(Round(x1), Round(y1), Round(x2), Round(y2), Radians(I/2));
    IncEx(Result[I].X, Round(x1+x2)/2);
    IncEx(Result[I].Y, Round(y1+y2)/2);
  end;
  for I := 0 to Round(x2-x1) do
  begin
    SetLength(Result, Length(Result)+2);
    Result[High(Result)-1] := Point(Round(x1)+I, Round(y1));
    Result[High(Result)] := Point(Round(x1)+I, Round(y2));
  end;
  for I := 0 to Round(y2-y1) do
  begin
    SetLength(Result, Length(Result)+2);
    Result[High(Result)-1] := Point(Round(x1), Round(y1)+I);
    Result[High(Result)] := Point(Round(x2), Round(y1)+I);
  end;
end;



procedure DrawPoints(TPA: TPointArray; DebugW, DebugH: Integer);
var
  Index, Bitmap: Integer;
begin
  Bitmap := BitmapFromString(DebugW, DebugH, '');
  for Index := 0 to High(TPA) do
  begin
    FastSetPixel(bitmap, TPA[Index].X, TPA[Index].Y, 65280);
  end;

  //GetBitmapCanvas(Bitmap);
  DisplayDebugImgWindow(DebugW, DebugH);
  DrawBitmapDebugImg(bitmap);
  //CopyCanvas(GetBitmapCanvas(Bitmap), GetDebugCanvas, 0, 0, DebugW, DebugH, 0, 0, DebugW, DebugH);
end;


function GaussianPoint(x1, y1, x2, y2: Integer): TPoint;
var
  Angle: Extended;
  Ep: TPoint;
  AAA: Extended;
begin
  Angle := RandomAngle;
  EP := EllipseOffset(x1, y1, x2, y2, Angle);
  AAA := Gaussian(1,  Abs(GaussianLimit));
  Result.x := Round((x1+x2)/2 + {cos(Angle)*}EP.X*AAA);
  Result.y := Round((y1+y2)/2 + {sin(Angle)*}EP.Y*AAA);

  //  Result.x := Round((x1+x2)/2+A*cos((Angle-2*Pi)));
  //  Result.y := Round((y1+y2)/2+B*sin((Angle-2*Pi)));
end;


function GeneratePoints(AmouthOfPoints, DebugW, DebugH: Integer): TPointArray;
var
  Index: Integer;
begin
  for Index := 0 to AmouthOfPoints do
  begin
    SetLength(Result, Length(Result)+1);
    Result[Index] := GaussianPoint(ox1, oy1, ox2, oy2);
  end;
end;


begin
  DrawPoints(CombineTPA(GeneratePoints(PointsToDraw, DebugW, DebugH), EllipsePoints(Ox1, Oy1, Ox2, Oy2)), DebugW, DebugH);
  //DrawPoints(GeneratePoints(PointsToDraw, DebugW, DebugH), DebugW, DebugH);
  //DrawPoints(EllipsePoints(Ox1, Oy1, Ox2, Oy2), DebugW, DebugH);
end.

Now I see that simba has some gaussian functions too. Are they documented anywhere?


Edit: which one you think is more human like if you had to click inside a box? Or perhaps something else? Perhaps option to choose? First one would never click the corners.

Id say the second one. Although a player might click the edge of an object I don't believe he'd (honestly) aim for it, and this might avoid some miss-clicks too.

-RM

From: Sir R. M8gic1an
Id say the second one. Although a player might click the edge of an object I don't believe he'd (honestly) aim for it, and this might avoid some miss-clicks too.

-RM

The ellipse edge points are not part of the gaussian points. They are just to visualize the limit where it can't click further. So it wouldn't aim the edges.

Edit: Got the second one done. I don't really like the result though.. Uploaded attachment. (The points outside of the box wouldn't be included)

Edit2: Uploaded second attachment. No ellipses or anything. Just random gaussian x value between x1 and x2 and same with y values. It looks better in my opinion.

https://github.com/Nava2/SRL-5/tree/gauss-implement

weequ compare and test. I'm willing to take yours over mine. Any work you do, give me a pull request and see what we can do :)

P.S. Only reason I was using mine was that it was fastest, but I'm down for using others. :)

Lulwut? This is way past my level of knowledge.

From: Invalid Gold
Lulwut? This is way past my level of knowledge.

The point is that human click would hit the center more often than the edges.

Lets say you tried to click a monster. You would aim at the center so your clicks would hit close to the center more often than the edges.

Most bots are as likely to hit the corners and it's detectable at least in theory.

Interesting reading. Enjoyed to know more about how Jagex tracks down bots, and how we can avoid it, making it 100% human!
Really Good Job Xtensity! Rep+

~onilika

E: Just read this thread, past 1 year LOL

From: weequ
The point is that human click would hit the center more often than the edges.

Lets say you tried to click a monster. You would aim at the center so your clicks would hit close to the center more often than the edges.

Most bots are as likely to hit the corners and it's detectable at least in theory.

Sure in theory. But i strongly doubt that Jagfex has a method of detecting which part of a model you clicked on.

I bring up my example of when my chicken script bugged out and ended up clicking on the other side of a wall, in the exact same coordinates, "I can't reach that" for over 48 hours. No ban at all.

Jagmix can only record so much information about a players activities, and somehow i don't feel they even record how random your clicks are.