SRL Archive - Research & Development Lounge

I am not sure if this is the right section to post this thread, but I'll do it regardless. If any person would find a better place for this thread, it may be moved.

Now, onto the topic. I'm not certain on how to explain this idea i got, but I think that a kind of algorithm that gradually reduces the script's efficiency with respect to time taken should make SRL a bit more human-like. Who plays for 6 hours with the same speed that they started with? I believe creating a normal distribution of efficiency and then limiting randomness to within an acceptable value on both sides of the median should create some individuality. (I do not know whether I've explained this well, since I'm yet to learn about Normal and Poisson distributions, being fifteen years old).

Maybe 100% efficiency for the first hour giving or taking away 3% and then 90% for the second hour, 81% for the third hour (a bit like radioactive decay) should do it. Anyway, this is just an idea that cropped up in my head at midnight (:cartman:) so you're all free to expand upon it and put in your views and suggestions. I would, personally, like to see this system implemented into SRL routines if it was possible and feasible, but it is not mine to decide. Anyway.

Yes this is real progressive think, nicely thought up! I love seeing ideas like this come into play. Simple logic mixed with a mimic of human behavior will make it seem like normal legit players are the bots. Well done mate.

Personally I don't think this should be standard in the SRL library but custom implanted in the scripter's work. In essence it should only be optional, not forced.

I had planned to do very similar routines in my AeroLib (that was never released), while both running duration and local time of the user would effect mouse movement, text-typing abilities and reaction time to in-game events. I had planned to go both ways, doing like what you cite here: efficiency over time is reduced further into run time, but I also planned to start out inaccurate in some small tasks the script would perform at first, and over time accuracy would improve; much like a human learning a pattern to training a skill efficiently over time. And like I said before, time of day would factor into this as well. Late at night most people wouldn't be so quick to react to in-game chat (ect) or not so accurate on clicking the right button on the screen.


Good thinking, Petite One. I truly hope you follow through with this and release an example or video example of your work thus far. I look forward to seeing more! :thumbsup:

Thank you for your thoughts, Flight!

As for your post, I believe that the average absolute value of the slope of the learning curve for most processes that are capable of being botted is much greater than that of an efficiency over time curve; simply because humans learn simple tasks faster than we get tired or bored. I think that this is made opposite in nighttime, where humans are generally unobservant of some nuances, being not nocturnal.

As for your final line, I am sorry that I neither have the time nor the experience to create something like this - I've just started learning Pascal and I'm in my final year of school and I have exams nearly every week. I wish good luck to anyone who tries this though, it should be entertaining at the least.

First you could make your min and max waits random

Procedure SeedWaits;
Begin
  C_1 := RandomRange(0,50)
  C_2 := RandomRange(100,250)
  C_3 := RandomRange(200,400)
  C_4 := RandomRange(500,850)
  C_5 := RandomRange(200,500)
  C_6 := RandomRange(700,1100)
  C_7 := RandomRange(100,300)
  C_8 := RandomRange(500,750)
  C_9 := RandomRange(300,500)
  C_10 := RandomRange(600,800)
  C_11 := RandomRange(400,700)
  C_12 := RandomRange(900,1500)
  MaxSleep := RandomRange(432,4848)
End;

Then you could make your waits random

Procedure FastWait;
Begin
  case random(1000) of
    1..860:    Wait(RandomRange(C_1, C_2));
    861..975:  Wait(RandomRange(C_3, C_4));
    976..1000: Wait(RandomRange(C_5, C_6));
  End;
End;

And then you could make a procedure that adds on to those randomly

I'm pretty sure ideas like this have been posted before. It wouldn't even be hard for a scripter to implement, it's as simple as adding a basic step-function to multiply the time of your waits, mouse speed, etc.

e.g.

function humandecay: extended;
begin
  case gettimerunning of
    0..2700000: result := 1.00;
    2700001..blah: result := 0.9;
end;

procedure dostuff;
begin
  dostuff;
  wait(700*humandecay);
end;

Not sure if good or bad idea..

I'm leaning towards bad because most people report bots/players that either play too long or too shitty.
Remember those bots that type 14 into the chat box when cutting bows? Well I consider that in-efficiency..

How will the bots get less efficient? By just slowing down? Or by actually reaching a breaking point at which it will probably really break or shutdown?

What do you consider in-efficient simulation?

This is a good idea, I'll show something that I built on this basis.

From: Brandon
Not sure if good or bad idea..

I'm leaning towards bad because most people report bots/players that either play too long or too shitty.
Remember those bots that type 14 into the chat box when cutting bows? Well I consider that in-efficiency..

How will the bots get less efficient? By just slowing down? Or by actually reaching a breaking point at which it will probably really break or shutdown?

What do you consider in-efficient simulation?

Lol I hate those nubs that don't just for colors or text in the fletching interface..

I did a whole slew of things in my fletcher for antiban:

wouldn't only type 27, would type it mostly but not always if not a random number
would do random random waits
not clicking a completely random part of the object
combination of brakemmouse and humanmmouse
sometimes left clicked a bank that you right click (misclick)


check it out in my siggy broken ATM because I have to update it for SRL - OSR

Someone has misunderstood me. What I was stating was a concept of the simulation of human fatigue in SRL.

Never assume everyone will understand your idea from the first post, Petite One :) I however understand it, and love the concept.

Keep it up! A proof-of-concept script or video always helps.

Definitely a good idea. You could have the user input some type of decay rate (decrease in efficiency per hour). Or you could just have the script randomly generate the decay rate, could make scripts appear to be much more random and hard to spot (especially if it was a high use script).

Along this train of thought I was thinking someone (hehe, not me) should make a better function for clicking in a box, in the sense that if you have a mousebox(x1,y1,x2,y2) generally the most clicks should appear near the center, not evenly distributed around the box.

From: cause
Definitely a good idea. You could have the user input some type of decay rate (decrease in efficiency per hour). Or you could just have the script randomly generate the decay rate, could make scripts appear to be much more random and hard to spot (especially if it was a high use script).

Along this train of thought I was thinking someone (hehe, not me) should make a better function for clicking in a box, in the sense that if you have a mousebox(x1,y1,x2,y2) generally the most clicks should appear near the center, not evenly distributed around the box.

Ill play around with this in my waterfiend killer once it is done being re written :P Also, I can look at the mousebox function and see if I can update it for you @cause

From: SRLKing
Ill play around with this in my waterfiend killer once it is done being re written :P Also, I can look at the mousebox function and see if I can update it for you @cause

Cool SRLKing, I look forward to it.

Actually, I have seen scripts (at least one) in my time here at Villavu that had a human fatigue system. I've always wanted to develop a decent system to do it, though, I just haven't had the time to put forth the effort to make it happen (yet).

From: cause
Along this train of thought I was thinking someone (hehe, not me) should make a better function for clicking in a box, in the sense that if you have a mousebox(x1,y1,x2,y2) generally the most clicks should appear near the center, not evenly distributed around the box.

In regards to more centered clicking, I also remember reading a thread on the same topic a LOONG while back, though, I don't remember the name of it. Wouldn't this do about what you want?

MMouse(x, y, Random(Random(5)), Random(Random(5)));

From: cause
Cool SRLKing, I look forward to it.

I'll be looking at it tomorrow, going to be gone all tonight at the Michigan game(:

From: Valithor
Actually, I have seen scripts (at least one) in my time here at Villavu that had a human fatigue system. I've always wanted to develop a decent system to do it, though, I just haven't had the time to put forth the effort to make it happen (yet).



In regards to more centered clicking, I also remember reading a thread on the same topic a LOONG while back, though, I don't remember the name of it. Wouldn't this do about what you want?

MMouse(x, y, Random(Random(5)), Random(Random(5)));

No that wouldn't quite do it, Mousbox automatically randomizes where it clicks inside the box.
I think how'd you would do it is to assign each pixel a weighting based on how far it is from the center pixel, then "randomly" choose but having the weights help determine the location of the click. This would probably be an empirical method based procedure, you'd probably want to paint onto SMART and change it until you decide a good weighting system. We just need to remember that after a certain number (usually 30) of any random occurrence of the same nature, we get a bell curve distribution. Anyways I think that's how'd I do it, however it might just be a lot of work for not too much gain though lol.

From: cause
No that wouldn't quite do it, Mousbox automatically randomizes where it clicks inside the box.
I think how'd you would do it is to assign each pixel a weighting based on how far it is from the center pixel, then "randomly" choose but having the weights help determine the location of the click. This would probably be an empirical method based procedure, you'd probably want to paint onto SMART and change it until you decide a good weighting system. We just need to remember that after a certain number (usually 30) of any random occurrence of the same nature, we get a bell curve distribution. Anyways I think that's how'd I do it, however it might just be a lot of work for not too much gain though lol.

procedure MouseBox(x1, y1, x2, y2: Integer; ClickType: Integer);
var
  fx, fy: Integer;
begin
  GaussBox(fx, fy, x1, y1, x2, y2);

  if InRange(ClickType, mouse_Right, mouse_move) then
    Mouse(fx, fy, 0, 0, clickType)
  else
    srl_Warn('MouseBox', 'ClickType is NOT a valid number!', warn_AllVersions);
end;

Mousebox is not 'random', yet rather distributed around the center with a Gaussian/normal distribution.

Hmm. maybe ill make a quick poc script to show the actual distribution of clicks. im thinking… 3d graph of the box?

edit, Running now. 50k points should be enough right?

And its done. Soo as we can see here… (did 50,000 clicks)
The left is just a plot of every single 'click' using MouseBox() with a size of 500x500. You can see its all in the middle, but to what extent?

The Right is the 3d graph of frequencies of the clicks. As you can see, it is centered around the middle of the box. (ignore the scale values, they are wrong as matlab throws a nice memory error when i try and make a 50000x50000 matrix, but it still shows the correct proportionality)

From: Turpinator

procedure MouseBox(x1, y1, x2, y2: Integer; ClickType: Integer);
var
  fx, fy: Integer;
begin
  GaussBox(fx, fy, x1, y1, x2, y2);

  if InRange(ClickType, mouse_Right, mouse_move) then
    Mouse(fx, fy, 0, 0, clickType)
  else
    srl_Warn('MouseBox', 'ClickType is NOT a valid number!', warn_AllVersions);
end;

Mousebox is not 'random', yet rather distributed around the center with a Gaussian/normal distribution.

Hmm. maybe ill make a quick poc script to show the actual distribution of clicks. im thinking… 3d graph of the box?

edit, Running now. 50k points should be enough right?

And its done. Soo as we can see here… (did 50,000 clicks)

The left is just a plot of every single 'click' using MouseBox() with a size of 500x500. You can see its all in the middle, but to what extent?

The Right is the 3d graph of frequencies of the clicks. As you can see, it is centered around the middle of the box. (ignore the scale values, they are wrong as matlab throws a nice memory error when i try and make a 50000x50000 matrix, but it still shows the correct proportionality)

Well look at that…nice man!! I haven't used matlab yet, but I expect I will in september (2nd year mechatronic eng)

getFatigue() returns the number of 10 minutes that has passed since script start by default.

You can change FatigueMethod to override this. (Say since the player has logged in?)

You can ether use this Fatigue to calculate what to add to waits, or just use it.

Starts at 0 and makes it's way to 480 at 8 hours.

program Fatigue;

type
  TFatigueMethod = function(): UInt32;

var
  FatigueMethod: TFatigueMethod = @GetTimeRunning;

function getFatigue(): UInt32;
begin
  Result := FatigueMethod() div 60000;
end;

function getFakeTime(): UInt32;
begin
  Result := GetTickCount();
end;

begin
  FatigueMethod := @GetFakeTime;
  WriteLn(getFatigue());
end;

From: Turpinator

procedure MouseBox(x1, y1, x2, y2: Integer; ClickType: Integer);
var
  fx, fy: Integer;
begin
  GaussBox(fx, fy, x1, y1, x2, y2);

  if InRange(ClickType, mouse_Right, mouse_move) then
    Mouse(fx, fy, 0, 0, clickType)
  else
    srl_Warn('MouseBox', 'ClickType is NOT a valid number!', warn_AllVersions);
end;

Mousebox is not 'random', yet rather distributed around the center with a Gaussian/normal distribution.

Hmm. maybe ill make a quick poc script to show the actual distribution of clicks. im thinking… 3d graph of the box?

edit, Running now. 50k points should be enough right?

And its done. Soo as we can see here… (did 50,000 clicks)

Nice graphs!
Lets say I need to click door and I use mousebox. It's good actually that we click more to the middle of door because humans (at least I) try to click the center of object

From: t4q
Nice graphs!
Lets say I need to click door and I use mousebox. It's good actually that we click more to the middle of door because humans (at least I) try to click the center of object

Check out guide in my signature shows exactly that

It's already implemented. MouseBox uses GaussBox, which uses gaussrange to choose a normally distributed point from x1 to x2 and y1 to y2. If you were to populate the mousebox area with points chosen by mousebox, it would be center heavy and borders light.
I had this idea too, came a little to late for the revolution :)

EDIT: Shit, I'm late again.