SRL Archive - Development

Correct me if I am wrong: Extensions can run in their own thread right? So, would it be at all possible to write a FindRandoms (and solve) extension?

One of the main problems with FindRandoms is that it out-times my scripts. Random solving simply takes too long and causes running timers to break out of critical loops. The FindRandoms extension should be able to intercept and pause the running script. Is this possible?

Bamp. I think this is a good idea, if it works.

Oh, wow. Good idea :)
Someone want to test this?

No, I don't think it would be. This is because the clients are created as the script runs. Currently, Simba supports multiple scripts running, thus there would be multiple clients.

You would also have to pause the script thread, which might be a pain, I'm not sure.

Its a *great* idea, but I really do not see it happening implementation wise.

Couldn't something be used to paused the script like we have start and stop for Forms.

~BraK

From: Nava2
You would also have to pause the script thread, which might be a pain, I'm not sure.

Pausing threads aren't that big of a deal, lol. Just don't use deprecated methods which may cause AV's over a period of time..

There really isn't much to do about this. You'll basically just have to increase your timers. All the other methods are generally way too complicated.

during repeats invloving timers if thats what you are on about cant you put a check rnadoms loop, and if it finds a random pause the timer, however i cant think of a way to restart the timer, unless maybe a second search for randoms which turns up false ,which starts the timers?

if you mean implementing hte pause into the actual random functions then i have no idea…

function WTRandoms(var timer: integer): boolean;
var
  t: integer;
begin
  t := GetSystemTime;
  Result := FindNormalRandoms;

  if Result then
    timer := timer + t - GetSystemTime;
end;

~RM

By the way, can 'GetSytemTime' be converted, into hours minutes and seconds?

for example to give a started at finished at time?

From: mat_de_b
By the way, can 'GetSytemTime' be converted, into hours minutes and seconds?

for example to give a started at finished at time?

It's probably a unix timestamp, so yes you can convert it into your current time.

I don't think it's a good idea. You might get situations where you pause the script in the middle of a movemouse (because you want to click a tree, for example) and continue after the random is solved. It will result in a click from which the script thinks that it's clicking on a tree. Because you don't know what's actually going on, it'll probably be harder to write scripts.

You don't need FindRandoms in timed loops. You need to break out of a loop if you find a random, or adjust (the length) the loop if necessary.

If you use the piece of Code I posted, you can just call that function and use whichever timer you need to adjust as an argument. So if there's only one timer that pretty much fixes your troubles ;)

~RM

From: nielsie95
I don't think it's a good idea. You might get situations where you pause the script in the middle of a movemouse (because you want to click a tree, for example) and continue after the random is solved. It will result in a click from which the script thinks that it's clicking on a tree. Because you don't know what's actually going on, it'll probably be harder to write scripts.

You don't need FindRandoms in timed loops. You need to break out of a loop if you find a random, or adjust (the length) the loop if necessary.

Pretty sure you only get randoms upon making an action though, such as a click on a tree. So the script wouldn't be in a position where it gets a random in between finding a tree, and clicking it - although it could get one after clicking a tree, in which case in most scripts FindRandoms is called anyway.

RM's would work but wouldnt with multiple timers, although that could be rectified by using a TIntegerArray…but would get tedius with many timers in many places. Unless you defined each timer in a single TIntegerArray at the start of a script, and then just reffered to that all the time.

Threaded antirandoms would be the most pro, though. :p

From: The Claw
Threaded antirandoms would be the most pro, though. :p

It would mainly be the most pointless. What if another ``thread'' spots anti randoms only; and just stops the script right there. Solves the random and then lets the script go its way again. The script will be completely lost, not even knowing a random was solved. Another way would be to only spot it and then tell the script it saw a random. And then what? There's no way to just break into where ever the script is at the moment and solve a random. It'll still have to be called as such: srl_CheckForNewRandomsByPollingTheOtherThread(). So instead of FindNormalRandoms; you call this. What's the big advantage? You'll be too late to solve the random fast anyway, as the thread may not even be in sync with your script and the random may have already disappeared or teleported you. At least if you call FindRandoms you know that you are in fact in a random now.

Wat. Have a parallel thread looking out for randoms, pause the script when a random is found, restart it when its either failed or solved. Logout in the antirandom thread if its failed, a good script will catch the logout and swap to the next player. As for the script not knowing it got a random, it doesnt need to, and I assume you can set variables in other threads that can be displayed in reports so the scripter/user will still know it solved/failed randoms. The idea is to get the scripter to not have to worry about finding randoms at all, but rather to have it searching all the time, once a second or whatever the person's computer can comfortably run. How many times have scripts messed up due to improper antirandom finding? That number would be 0 if its ALWAYS checking for antirandoms at set intervals.

AFAIK Rsbot and many other Java bots did it like this

From: The Claw
AFAIK Rsbot and many other Java bots did it like this

They actually kill all threads on a failed random.

This is a great idea! One aspect that needs mentioning (sorry if someone already said this, i didn't really read the thread :P) is that the extension should pause time, so that scripts that use timing don't get thrown off.