SRL Archive - SRL Snippets

I've been playing around trying to change graphics settings during login. I found that if your graphics are set to either mid or high and the screen is resizable, the RSReady function does not see that and so the script eventually terminates. Here is my suggestion for a revision:

function RSReady: Boolean;
var
  x, y: Integer;
begin
  Result := (LoggedIn) or (LobbyScreen);
  if (not Result) then
  begin
    ImageResetClientArea;
    Result := (GetColor(745, 17) = 16645629) or FoundBar; // X button in top right && Navigation Bar.
    SRL_ResetNavBar;
  end;
  if (GetColor(755, 43) = 16645629) then  // X button on resizeable client
  begin
    WriteLn('You are using the "Resizeable" screen option in RS.');
    WriteLn('Changing to "Fixed" screen option.');
    Mouse(735, 44, 2, 2, mouse_Left);
    Wait(600 + Random(800));
    if FindBitMapToleranceIn(SRL_OPTIONS_BITMAP, x, y, 130, 40, 640, 265, 5) then
    begin
      Mouse(200, 270, 5, 5, mouse_Left);  //Fixed button
      Wait(1200 + Random(1200));  //Wait while the screen changes
      Mouse(621, 71, 3, 3, mouse_Left); //Close the Options interface
      Wait(600 + Random(240));
    end
    else
    begin
      WriteLn('Unable to find Options Screen.');
      WriteLn('Please manually change to "Fixed" screeb size');
      TerminateScript;
    end;
  end;

  // Loragnor - 6-22-2013
  // Check for resizable clients in mid or high graphics
  if(GetColor(736,-9) = 16645629) then
  begin
    WriteLn('You are using the "Resizeable" screen option and either mid or high graphics.');
      WriteLn('Changing to "Fixed" screen and min graphics options.');
    Mouse(736, -9, 1,1,mouse_left);    // Open the options screen
    Wait(600 + Random(800));
    if FindBitMapToleranceIn(SRL_OPTIONS_BITMAP, x, y, 130, 40, 640, 265, 5) then
    begin
      Mouse(200, 270, 5, 5, mouse_Left);  // Fixed button
      Wait(1200 + Random(1200));          // Wait while the screen changes
      Mouse(230,180,5,5,mouse_left);      // Change to min graphics
      Wait(1200 + Random(1200));          // Wait while the screen changes
      Mouse(621, 71, 3, 3, mouse_Left);   // Close the Options interface
      Wait(600 + Random(240));
    end
    else
    begin
      WriteLn('Unable to find Options Screen.');
      WriteLn('Please manually change to "Fixed" screen size');
      TerminateScript;
    end;
  end;

  if (FindBitMapToleranceIn(SRL_OPTIONS_BITMAP, x, y, 130, 40, 640, 265, 5)) then
  begin
    Writeln('Failed to close Options Interface. Please report on Villavu Forum');
    TerminateScript;  //Failsafe if we fail to close the Interface for some reason
  end;
end;

I could see this happening, I'd advise that looking into more dynamic-like code should help your idea grow (possibly towards the includes too if you so choose).

Red flags I see at the moment: frequent waits (maybe some loops with failsafe checks to help optimize experience), Lack of include use (srl warn), excessive writeln's, color checking concerns (with re-sizable, I know the 'X' is suppose to be in a certain spot, but what if the window somehow gets smaller width wise, and the 'X' moves upwards? - perhaps checking instead for if the safemode isn't present, then re-sizable precautions may be taken place), and static clicks. I only mean to criticize in the most respect and hopes to help better coding via my personal perspective.

Cheers,
Lj

From: Le Jingle
I could see this happening, I'd advise that looking into more dynamic-like code should help your idea grow (possibly towards the includes too if you so choose).

Red flags I see at the moment: frequent waits (maybe some loops with failsafe checks to help optimize experience), Lack of include use (srl warn), excessive writeln's, color checking concerns (with re-sizable, I know the 'X' is suppose to be in a certain spot, but what if the window somehow gets smaller width wise, and the 'X' moves upwards? - perhaps checking instead for if the safemode isn't present, then re-sizable precautions may be taken place), and static clicks. I only mean to criticize in the most respect and hopes to help better coding via my personal perspective.

Cheers,
Lj

Thank you @Lj for the response. Any helpful criticism is very appreciated.

I am not trying to rewrite login.simba. I do not understand enough of the logic yet to make such an attempt. I merely saw that something I wanted to do was not happening and traced it to this procedure. As you can see, I've merely copied, pasted and modified the previous if..then block. So, this is not an original idea.

For waits, I assumed it was to mimic a human looking on the screen and moving the mouse to the desired click location, so I left them in place.

For failsafes, this procedure is actually only called by login->LoginPlayerToLob which gives it a 3 minute timeframe to find a button and make changes. At the end of the 3 minutes, the script terminates.

As for dynamic code, I had wanted to be a bit more elegant. In other languages, it is possible to create if..elseif..elseif..else blocks, but I was unable to find any reference to such except to nest if..then blocks. If this is possible, I would sure appreciate a nudge in the direction of some deeper education.

To cut down on the verbose nature of this modification, I removed several written comments.

As for the methodology (checking safemode versus button location), I agree that would be much better. However, as I said, I am not trying to rewrite login.simba. Additionally, I have no idea how to check the state of the graphics to determine if it is in safemode or not. I will look into it though.

Thank you again.

I would absolutely love to give you a more in depth response than what's coming, but typing on my cell phone is impressively annoying.
So, for starters, PascalScript/Lape do support If/elseif/else statements with the exact same format as other languages (with the exception being instead of brackets, having begin….end; instead.

if(i=3)then
begin
  //stuff
end else if (i=4)then
begin
  //other stuff
end else begin
  //last stuff
end;

or you can use case statements like this:

case i of
  3:begin  end;
  4:begin  end;
  else:begin  end;//else: stands for the default case you see in most languages
end;//notice the overall statement case has an end but no begin 

@Kevin, thanks for the code lesson. I see the loop structure now and miss my brackets. I'm also impressed with your cell phone typing skills. :)

None of this code will work for people not using SMART.

But anyways, You can prob detect a re-sizable client just by getting client size. Then use the size to calculate the positions of buttons and stuff.

From: Dgby714
None of this code will work for people not using SMART.

But anyways, You can prob detect a re-sizable client just by getting client size. Then use the size to calculate the positions of buttons and stuff.

Frankly, it had not even occurred to me that someone would be using this particular function or even the file login.simba without also using SMART. I suppose that is a possible issue, but since it seems the intent was for this file to be used with SMART, I'll not be concerned with a different outcome.

I wonder, concerning larger and smaller windows and client sizes and all the rest, if that is a possibility? I mean, the SMART client itself is not realizable and the original version of this particular function looks for the "X" to be in a particular spot in the client. How many other SCAR and Simba functions and procedures do the same thing? If there were a change in the size of the client window, all these would break and there would be chaos and anarchy in the world. :( It seems to me that the intent is for the client to remain a fixed size and so locating an "X" is as simple as looking in a particular spot for it.

From: loragnor
Frankly, it had not even occurred to me that someone would be using this particular function or even the file login.simba without also using SMART. I suppose that is a possible issue, but since it seems the intent was for this file to be used with SMART, I'll not be concerned with a different outcome.

I wonder, concerning larger and smaller windows and client sizes and all the rest, if that is a possibility? I mean, the SMART client itself is not realizable and the original version of this particular function looks for the "X" to be in a particular spot in the client. How many other SCAR and Simba functions and procedures do the same thing? If there were a change in the size of the client window, all these would break and there would be chaos and anarchy in the world. :( It seems to me that the intent is for the client to remain a fixed size and so locating an "X" is as simple as looking in a particular spot for it.

The difference is, that this is one of the first methods to be called, if it can handle many different sizes dynamically, and fix RS's settings accordingly, none of the other methods have to worry.

Also, Why did it not occur to you that this method would be used without SMART?

Even without SMART, SRL still needs to know if RS is there and ready?

Maybe has RSReady detect dynamically, and the login method fix settings?

From: Dgby714
Also, Why did it not occur to you that this method would be used without SMART?

Even without SMART, SRL still needs to know if RS is there and ready?

It did not occur to me because I've been active here for about a month and the uses for any of this code base outside of creating a bot for RS using the SMART client have not been on my radar at all. I am, admittedly, ignorant about using SRL with a browser or even another client that someone else may create. Neither of these scenarios is within my scope of interest, so it just didn't occur to me.

From: Dgby714
Maybe has RSReady detect dynamically, and the login method fix settings?

This would be more intuitive to me since the name of the function and the boolean return suggest a simple check for readiness, perhaps meeting certain criteria. But, I did not design or write it. I am merely reporting that it did not work as I expected it to and suggested a fix that made sense to me. :shrug:

From: loragnor
It did not occur to me because I've been active here for about a month and the uses for any of this code base outside of creating a bot for RS using the SMART client have not been on my radar at all. I am, admittedly, ignorant about using SRL with a browser or even another client that someone else may create. Neither of these scenarios is within my scope of interest, so it just didn't occur to me.



This would be more intuitive to me since the name of the function and the boolean return suggest a simple check for readiness, perhaps meeting certain criteria. But, I did not design or write it. I am merely reporting that it did not work as I expected it to and suggested a fix that made sense to me. :shrug:

With the process for how large project code development works, I would suggest a straight up replacement for RSReady that instead of returning a boolean would return aforementioned criteria that login could fix. (that way RSReady could still be called outside of Login by individual people without breaking their scripts).

As for non-SMART related scripts, they do exist as technically we are a community focused on Object Color Recognition (OCR), merely using Runescape as our focus. We also touch on many similar areas such as 07 and RSPS, and even several flash games I've seen online that people have scripted for here. And beyond even that, not everyone chooses to use SMART due to a fear of being detected that doesn't quite exist nearly as much from using SIMBA and an actual client.

From: Kevin
With the process for how large project code development works, I would suggest a straight up replacement for RSReady that instead of returning a boolean would return aforementioned criteria that login could fix. (that way RSReady could still be called outside of Login by individual people without breaking their scripts).

Hm. RSReady would need to either accept parameters or use global vars that would define what the user or scripter is expecting. To afford backward-compatability, it would still need to return a boolean, but login itself should call another function or series of functions that would correct the graphics and / or audio settings.

From: Kevin
As for non-SMART related scripts, they do exist as technically we are a community focused on Object Color Recognition (OCR), merely using Runescape as our focus. We also touch on many similar areas such as 07 and RSPS, and even several flash games I've seen online that people have scripted for here. And beyond even that, not everyone chooses to use SMART due to a fear of being detected that doesn't quite exist nearly as much from using SIMBA and an actual client.

Thanks for this. It broadens my perspective.

From: loragnor
Hm. RSReady would need to either accept parameters or use global vars that would define what the user or scripter is expecting. To afford backward-compatability, it would still need to return a boolean, but login itself should call another function or series of functions that would correct the graphics and / or audio settings.

I don't mean another function named RSReady. I mean an entirely new function ie:

function RsReadyEx(params: TVariantArray): boolean;

Similar functionality and this would now be called via LoginPlayer instead (which could then call something else to fix the graphics). That way, the current RSReady remains unchanged (parameter/return value-wise at least) for backwards compatibility with scripts that directly call it while we still gain the new desired functionality in a new function.

Thanks for this. It broadens my perspective.

You're welcome :p

From: Kevin
I don't mean another function named RSReady. I mean an entirely new function

Well, get to writin'. ;)

Hard to think no one has suggested to do this or noticed this limitation before.

From: loragnor
Well, get to writin'. ;)

Hard to think no one has suggested to do this or noticed this limitation before.

Well, it's not much of a limitation because it would require someone changing their graphics settings between scripts as ALL scripts (that I know of) use the exact same simple graphics settings.

Although I would be curious to know if graphics settings would be something Jagex looks at as a first check to before looking into an account for possibly being a bot?

From: Kevin
Well, it's not much of a limitation because it would require someone changing their graphics settings between scripts as ALL scripts (that I know of) use the exact same simple graphics settings.

I know that I personally like to see the graphics in HD sometimes. In fact, I'd run around with low settings for so long to cut back on lag, that when I did see the HD, I was fairly amazed.

From: Kevin
Although I would be curious to know if graphics settings would be something Jagex looks at as a first check to before looking into an account for possibly being a bot?

I'm not sure either, but both their client and applet do an auto detect for graphics settings and boosts them to HD even before you login. They could be noting who is using low settings. I don't know.

Although I would be curious to know if graphics settings would be something Jagex looks at as a first check to before looking into an account for possibly being a bot?

I'm not sure either, but both their client and applet do an auto detect for graphics settings and boosts them to HD even before you login. They could be noting who is using low settings. I don't know.

This would be a question for someone watching this type of stuff more heavily. Perhaps @Flight would have a solid idea for the likelihood of them doing this is (I guarantee it's possible, it's just a matter of the likelihood they care).

From: Kevin

I'm not sure either, but both their client and applet do an auto detect for graphics settings and boosts them to HD even before you login. They could be noting who is using low settings. I don't know.

This would be a question for someone watching this type of stuff more heavily. Perhaps @Flight would have a solid idea for the likelihood of them doing this is (I guarantee it's possible, it's just a matter of the likelihood they care).

I would seriously doubt they take graphics settings into account when determining if a player is using a 3rd party client and/or macroing. I'm sure they're well aware many computers can't handle serious graphics and a bulk amount of players prefer the lowest settings possible for that smooth experience. If they were ever to take graphics settings into consideration for bot detection I'd say it would be the mode they look at, like Safemode, OpenGL, DirectX. If a computer can run RS better (or the same) in, let's say, OpenGL than it could in Safemode then perhaps they might take this into consideration. But for small things like lowest water detail, no ground blending & textures; I don't see this as ever being a red flag for botters.

So in my own opinion the graphics settings of a player is far from enough proof to get you banned; it really shouldn't be anything to worry about. There's far too many reasons one could use to appeal a graphics-related ban from Jagex.

Just my two cents. ;)

From: Flight
Just my two cents. ;)

Thanks @Flight. Any input on the topic of RSReady?

From: loragnor
Thanks @Flight. Any input on the topic of RSReady?

Yeah I think this is a great idea, and I like Dgby714's advice as well. For the waiting, however, perhaps it would be nice to use something like WaitFindColor (or whatever it's called) that waits until a certain color is found in a specific area, as opposed to static wait times, ya know?

From: Flight
I would seriously doubt they take graphics settings into account when determining if a player is using a 3rd party client and/or macroing. I'm sure they're well aware many computers can't handle serious graphics and a bulk amount of players prefer the lowest settings possible for that smooth experience. If they were ever to take graphics settings into consideration for bot detection I'd say it would be the mode they look at, like Safemode, OpenGL, DirectX. If a computer can run RS better (or the same) in, let's say, OpenGL than it could in Safemode then perhaps they might take this into consideration. But for small things like lowest water detail, no ground blending & textures; I don't see this as ever being a red flag for botters.

So in my own opinion the graphics settings of a player is far from enough proof to get you banned; it really shouldn't be anything to worry about. There's far too many reasons one could use to appeal a graphics-related ban from Jagex.

Just my two cents. ;)

I do not mean for it to be remotely considered proof. But merely a 'mark' so to say of a possibility of an account to watch more closely. IE: Bot-watch ignoring accounts on higher settings and not even bothering with them, or simply watching the lower settings more closely for similarities.

RSReady is just a method that states the client has gone thru it's loading and ready for input.

Maybe we should add FixSettings? Allow scripts to set their preferred settings?

Instead of integrating it with any method?

RSReady still needs a modification to detect if the client is ready at any size, and FixSettings should be able to navigate to and in the settings menu at any size.

If we go the FixSettings method, there is no need to modify login.

From: Dgby714
RSReady is just a method that states the client has gone thru it's loading and ready for input.

Maybe we should add FixSettings? Allow scripts to set their preferred settings?

Instead of integrating it with any method?

RSReady still needs a modification to detect if the client is ready at any size, and FixSettings should be able to navigate to and in the settings menu at any size.

If we go the FixSettings method, there is no need to modify login.

I agree. There are already a few procedures that do some of this work. I haven't tested them yet to know if they are still useful. Some are pretty old.

login.simba -

procedure Login_SetAudio(Volume, SFX, Area: Integer; SMSetting: TSMSetting); {If not loggedin}

procedure Login_SetGraphics(Brightness: Integer); {if not loggedin}

procedure SetAudioOff; {Calls SetAudio(1, 1, 1, NoChange) if loggedin or Login_SetAudio(1, 1, 1, NoChange) if not loggedin}

procedure SetAutoingDefaults; {Calls FixGraphics if loggedin or Login_SetGraphics(4) if not loggedin}

gametab.simba -

procedure FixGraphics; {if loggedin opens the options tab and makes changes}

procedure SetGraphics(Brightness: Integer; vl, rr, gd, td, ia, fe, gt, cs: string); {Outdated since 2 SEP '09}

procedure SetAudio(Volume, SFX, Area: Integer; SMSetting: TSMSetting); {if loggedin opens the options tab and makes changes}

procedure SetBar(Brightness, Volume, SFX, Area: Integer); {Appears to work if loggedin and on the options tab}

Probably ought to test these procedures and see which will do what is required. We may not need to actually write anything much. Difficulty is that these mostly are used when logged in where as I was trying to do them before login. Do setting changes carry over through the next login? Or do they need to be reset?