View Full Version : QUESITON: Using wait, randomRange, and random as basic anti-ban
Incurable
08-25-2014, 11:26 AM
Sup,
I'm using "wait(randomRange(int, int))" as basic anti-ban between some actions in my scripts, but I think that waiting for a period between two values like "500" and "1000" every time the script goes through the procedure is far too bot-like and would be the exact kind of thing that Jagex would detect. A little bit of searching found that you can add "+ random(int)" inside of randomRange() for even more randomness, like this:
wait(randomRange(500 + random(50), 1000 + random(50)));
But I'm unsure as to just how much or little would would be necessary. Should I stick to small numbers (20-50) for smaller ranges, and larger numbers (200-500) for larger ranges, or should I be just be sticking to smaller ranges for everything? Or, should I just scrap the idea altogether?
Finally, am I actually understanding random(int) right? I can't find any documentation for it... it does actually return a random int between 0 and the given int, right?
Thanks for the help. ;)
By adding those extra random 50ms all you're doing is making the time to wait between 500ms and 1050ms, so there's still a static window and there always will be. Instead of using a random range you could just do a random wait, so going from 0 to, for example, 5000ms. That might look a bit more human like as the human could delay by something as small as 10ms.
And you're right on Random; that's exactly what it does.
Incurable
08-25-2014, 11:42 AM
By adding those extra random 50ms all you're doing is making the time to wait between 500ms and 1050ms, so there's still a static window and there always will be. Instead of using a random range you could just do a random wait, so going from 0 to, for example, 5000ms. That might look a bit more human like as the human could delay by something as small as 10ms.
And you're right on Random; that's exactly what it does.
My idea is that the static window would look less like a human wrote it if you added a random to it. For example, I have a bad habit of always writing neat wait times between numbers divisible by 500, and that sounds far too neat and scripted to me. If that static window was between 486 and 1072 instead of 500 and 1000, wouldn't that look more human?
I'm not quite sure I follow the second half of your post, are you suggesting using a really long wait time so that the ms returned is in a much larger range? Because that sounds inefficient when you just want to wait a short amount of time, but don't want to move on to the next action almost instantly.
Thanks.
EDIT: I suppose that you could even use GetTimeRunning to change the window after a random amount of time, but that could just be too much...
I suppose using more obscure numbers do make sense.
And I was just giving 5000ms as an example. What I mean is that instead of using a range of 500ms and 1000ms like you gave in your first post you could simply use a Random(1000) (or something like 1092 for a more obscure number), because a human might not always pause for a minimum of half a second; it could be a very brief delay.
Incurable
08-25-2014, 11:56 AM
I get it now, thank you, but wouldn't random(1000) have a chance of returning a very low number like 30, therefore making the next action almost instant, hence the use of randomRange?
I'm sorry if my questions are repetitive, thanks again.
EDIT: I think I'm just going to have to remember to force myself to use obscure numbers on top of randomness, as you suggested. :p
Mr. Roboto
08-25-2014, 12:29 PM
I get it now, thank you, but wouldn't random(1000) have a chance of returning a very low number like 30, therefore making the next action almost instant, hence the use of randomRange?
I'm sorry if my questions are repetitive, thanks again.
EDIT: I think I'm just going to have to remember to force myself to use obscure numbers on top of randomness, as you suggested. :p
Yes. To avoid the almost instant you want a lower bound and a higher bound. If I am not mistaken the higher bound is exclusive. So code like this:
randomRange(1, 10); Can produce:
1, 2, 3...9
slacky
08-25-2014, 12:42 PM
I get it now, thank you, but wouldn't random(1000) have a chance of returning a very low number like 30, therefore making the next action almost instant, hence the use of randomRange?
I'm sorry if my questions are repetitive, thanks again.
EDIT: I think I'm just going to have to remember to force myself to use obscure numbers on top of randomness, as you suggested. :p
The numbers are random, so there is just as big a chance of RandomRange(0,1000) returning 599, as there is for it returning 1, the chance in this case for any number from 0, to 999 is "1 in 1000". If you add another Random(50) to that.. you simply write RandomRange(0,1050) in a more clumsy way, as mentioned. It does not make it "more random", random+random=random no matter what you do.
An alternative to a random number, is to use a gaussian function to produce a normally distributed number, a number that usually ends up as `mean` +/- the `standard deviation`, but it has the property to generate peaks that are (much) further away then the standard dev, making it very optimal for things like these.
(*
Mu is the mean, sigma is the standard deviation.
*)
procedure GaussWait(Mu,Sigma:Double; vmin:Double=30);
var t,g:Double;
begin
t := 2 * PI * Random();
g := mu + (sigma * Sqrt(-2 * Ln(Random()))) * Cos(t);
// WriteLn('Waiting: ', Round( MaxE(g,vmin) ),'ms');
Wait(Round(MaxE(g,vmin)));
end;
begin
//wait normally around 700ms +/- 200ms, except for peaks which will/can go far above, or far below.
GaussWait(700,200);
end.
The example code, could peak as low as 30 (a limit is set), and over 1600ms, but usually ends up between 500 and 900ms.
Incurable
08-25-2014, 01:20 PM
The numbers are random, so there is just as big a chance of RandomRange(0,1000) returning 599, as there is for it returning 1, the chance in this case for any number from 0, to 999 is "1 in 1000". If you add another Random(50) to that.. you simply write RandomRange(0,1050) in a more clumsy way, as mentioned. It does not make it "more random", random+random=random no matter what you do.
An alternative to a random number, is to use a gaussian function to produce a normally distributed number, a number that usually ends up as `mean` +/- the `standard deviation`, but it has the property to generate peaks that are (much) further away then the standard dev, making it very optimal for things like these.
(*
Mu is the mean, sigma is the standard deviation.
*)
procedure GaussWait(Mu,Sigma:Double; vmin:Double=30);
var t,g:Double;
begin
t := 2 * PI * Random();
g := mu + (sigma * Sqrt(-2 * Ln(Random()))) * Cos(t);
// WriteLn('Waiting: ', Round( MaxE(g,vmin) ),'ms');
Wait(Round(MaxE(g,vmin)));
end;
begin
//wait normally around 700ms +/- 200ms, except for peaks which will/can go far above, or far below.
GaussWait(700,200);
end.
The example code, could peak as low as 30 (a limit is set), and over 1600ms, but usually ends up between 500 and 900ms.
That explanation made perfect sense, thank you.
GaussWait looks very interesting, could you expand on the names of the variables used? I understand how it works (I think), but I'm not sure what vmin, t, g, Ln, and MaxE are and I would like to know before I steal it. ;) Scrap that, I Googled the crap out of it. That is a wicked procedure and I'll be using it, thank you for sharing.
slacky
08-25-2014, 02:02 PM
That explanation made perfect sense, thank you.
GaussWait looks very interesting, could you expand on the names of the variables used? I understand how it works (I think), but I'm not sure what vmin, t, g, Ln, and MaxE are and I would like to know before I steal it. ;)
Thank you to everyone who posted.
`g`: short for gaussian, it holds the produced value, this number gets limited by a lower bound (vmin), otherwise it could "peak" to a negative number if the Sigma (std dev) is too high compared to Mu (mean),
and that is something we don't want in this case.
`vmin`: is the minimum waittime allowed in the GaussWait-function, it's automaticly set to 30ms, which might seem a bit low (depending on what's happening next).
But controlling the vmin to much makes the outcome more predictable, as it's more controlled, which is of course not a good thing. So I default it at 30ms, as I don't want it to limit to many lower-value peaks.
- You should never need change it, unless it's to set it even lower. Decrease the sigma if anything, that will also limit the peaks, but in a better manner..
`t`: is just short for theta, and is part of what produces the "angle" (in radians) which we "project" our outcome value at.
* Function can easly be modified to spit out two independent cartesian-values, one for x, and one for y, not that it matter now, but maybe it helps you to wrap your head around what's actually happening.
`MaxE`: is a function that returns the larger of the two given floating-point numbers, MaxE(1.0, 10.0) would return 10.0.
`Ln`: computes the natural logarithm (http://en.wikipedia.org/wiki/Natural_logarithm) of a number.
`Random()`: produces a random floating point value between 0.0 and 1.0.
My bad, I skim-read your first post and didn't see that this was for waiting between separate action, just assumed it was a standalone anti-ban method!
Incurable
08-25-2014, 02:23 PM
-snip-
Thank you, it's much appreciated. I'm already in love with GaussWait. :p
My bad, I skim-read your first post and didn't see that this was for waiting between separate action, just assumed it was a standalone anti-ban method!
No problem, thanks anyway!
o0Matthius0o
08-31-2014, 04:38 AM
Why not just use the built in anitban that comes packaged with srl?
Incurable
08-31-2014, 02:57 PM
Why not just use the built in anitban that comes packaged with srl?
I do, I was just asking about waiting between actions. :p
o0Matthius0o
08-31-2014, 07:41 PM
I do, I was just asking about waiting between actions. :p
Ohhh... my bad lol. I thought you were trying to re create your own anti ban. Which is a mistake I made.ugh... I was so relieved when I found all the built in anti ban
Powered by vBulletin® Version 4.2.1 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.