SRL Archive - Bugs & Improvements S.M.A.R.T.

The Problem:
You may have noticed that SMART now runs within Scar's process, and hence so does Runescape. At the time I did not see this as a problem, but now I see that it is. The good news is that SMART now runs perfectly, I ran Wizzup's VEM for about 4 hours. The bad news is that it was laggy as hell. As far as I can tell, this is due to RS taking away from Scar's avaliable process-processing-power, which makes Scar lag, further lagging the process as it spirals into a lockdown. Now I've looked into the options and I would like feedback.

The Solution(s):
First I would like to say that SMART needs to stay in Scar's process, so taking it out really isn't an option. The least desiarable solution would be for me to experiment with Thread and Process priority levels. Why I don't like this option is obvious (to me), it will take away from the whole idea of autoing while you do other things by making you're computer lag. My next, and most conterversial option, is to lower the "frame rate" of the client from its ungodly 'as-fast-as-possible' speed down to something like 20-30 fps. You will hardly notice the graphical difference, Scar won't have a clue anything has changed, and instead of using 50-80% of you're processor, you could get away with 15%-40%. This should compensate for anything Scar can throw at SMART. Now, I prefer that option, and I'll tell you why. First off, it requires no edits to Runescape, or anything else. Secondly, it is impossible to detect by programatical means (ie. from within Runescape). What I will do is simply slow down the thread responsible for rendering Runescape. That will only affect how fast the client is redrawn, and will have no visible affects.

The Question:
Is anyone adverse to having a client that uses less processor power than the normal RS? In reality, I shouldn't even have to ask that, but I don't want anyone getting angry at me ;)

From: BenLand100
The Problem:
You may have noticed that SMART now runs within Scar's process, and hence so does Runescape. At the time I did not see this as a problem, but now I see that it is. The good news is that SMART now runs perfectly, I ran Wizzup's VEM for about 4 hours. The bad news is that it was laggy as hell.

You should know that mainly when mining my VEM can be laggy, as I try to make the best out of the processor. ;)

I tried my DVM today with SMART, and it works (yes).
Although when I minimize the Client, SCAR's color finding no longer works, tricking the script into thinking my player has logged out.
Should I also overwrite all SCAR's colorfinding?

And I say go for it! (the lower fps client)

I've noticed the same thing wizzup, what i did was totally move it off screen (only a little edge remained). That did seem to work.

And i also say, go for it :)

I've noticed the minimizing problem also… it's random as far as I can tell. Run a script that copies the screen to the debug window and tell me if you see anything odd.

program New;

begin
  SmartSetup('ams3', false, false);
  SetTargetDC(SmartGetDC);
  FindWindowBySize(765,503);
  DisplayDebugImgWindow(765,503);
  repeat
    //Controlls the frame rate. Lower it for a smoother picture
    Wait(50);
    //Since the target is set, its now the client canvas.
    CopyCanvas(GetClientCanvas,GetDebugCanvas,0,0,765,503,0,0,765,503);
  until False;
end.

This is what I used and it won't work.
It doesn't 'follow' the client.

Just in case anyone else is wondering, don't use this:

 FindWindowBySize(765,503);

I also have problems when minizing,
It 'tricks' (as wizzup said) scar into thinking my inventory is full, and then stats walking to the bank.(VEM)
Bu the lower frame rate helped a lot, if you can lower it more w/o any harm to runescape/scar that would be great.

I haven't got a CLUE what is causing problems minimizing. Unless Freddy changed something internally, it should be working fine. I put a copy-to-debug during VEM's setup and it always came out perfect, minimized or covered, however it was not able to detect the pick color even… I'm not sure what the problem is.

How can I have changed something internally? Half of the people using SMART are using the same SCAR as they did for all previous SMART versions

From: Freddy1990
How can I have changed something internally? Half of the people using SMART are using the same SCAR as they did for all previous SMART versions

Actually 3.12 & 3.11 came out between old SMART and Embedded SMART. ;) But, no one really got this far into testing then. I'm thinking its a little quirk somewhere deep withing Scar. I mean, if you use either of the set target's its supposed to redirect all color searching right? Unless you are checking if the target window is on top before searching, there should be no difference in covered and uncovered, but there is.

More clearly, it works fine using Scar's procedures as long as Smart is not covered. However when its covered, or minimized, it gets confused. I know it sounds like an error within SMART, however a CopyCanvas of the client canvas always gives an unobstructed view, but Scar's searching fails. The only reason for that (that I know of) would be that something is preventing Scar from searching related to whether or not the target window (not image) is visible.

Edit: This could be persistent between previous versions of Scar, however I only have 3.06 (which doesn't run VEM anymore) and 3.12 which doesn't work ;)

From: BenLand100
Actually 3.12 came out between old SMART and Embedded SMART. ;) But, no one really got this far into testing then. I'm thinking its a little quirk somewhere deep withing Scar. I mean, if you use either of the set target's its supposed to redirect all color searching right? Unless you are checking if the target window is on top before searching, there should be no difference in covered and uncovered, but there is.

There are no checks for the windowposition at all… But erm 3.12 didn't come out, for example our good friend Yohojo here is not in possesion of SCAR 3.12 Beta…

Maybe some SRL procedures that are being used are using FindRS?

Just call the special smart set target at the beginning of your mainloop, or replace FindRS in SRL with a blank procedure.

I had already overridden FindWindowBySize so findRS wouldn't be causing a problem. In fact, I know SMART is targeted correctly, and I know that the proper image is getting to Scar, its just that Scar can't reliably search for colors when the window (not the image) is obstructed…

True ben, but i added a FindRS, and made it always true in my smart.scar anyways.
Do you mind posting a version of the VEM you use benland?
I have no idea why i thinks im inventory is full when i minimize.

I have no idea if this helps Ben, but here it goes,

i dont know if you know vista a bit or not, but when you hold your mouse on something in the task bar it will show a realtime thumbnail of the programme. When SMART isnt minimized it will change, meaning i can see the player walking in the thumbnail, when its minimized, it only shows the image that was on when i minimised it.

From: Sumilion
I have no idea if this helps Ben, but here it goes,

i dont know if you know vista a bit or not, but when you hold your mouse on something in the task bar it will show a realtime thumbnail of the programme. When SMART isnt minimized it will change, meaning i can see the player walking in the thumbnail, when its minimized, it only shows the image that was on when i minimised it.

I don't let it render to the game screen while minimized, saves a little processor power. Thats why you can't see it move while minimized. However, that does not affect Scar since thats not where Scar is getting the image.

Makes sense … :)

From: Sumilion
Makes sense … :)

Yes, it's very smart-like.