SRL Archive - Development

I'm creating this thread to avoid all the clutter with the other thread. Please don't post asking when ``SRL or Simba'' will work again.

So Benland and I agreed it would be useful to have a function SetClientArea and ResetClientArea in Simba. This would allow you to specify a specific part of the client as Simba area. All coordinates would be relative to this area.

This could be used to change the client area relatively to this new ``bar''. I'll try to make the operation as inexpensive as possible. (That is, cut down on the time it will take to do perform the call)

Usage would be something like:

SetClientArea(0, 42, 31415, 1337);

Functions affected would be: MoveMouse, GetMousePos (Which is, all mouse functions), ReturnData (everything Find* and GetColor), GetClientDimensions (would be the dimension of the area).

The effect of SetClientArea will probably be voided once a SetTarget<Bitmap|Array|Etc> is called. You will need to reinstate the area by calling SetClientArea function again.

Note that I have not yet written this function. If we're lucky, I can write this tomorrow and add it to Simba 0.99.(1). Once it works and SMART also works I think we'll just throw everyone to the new Simba. I'm not going to backport this to Simba 98x.

Suggestions, input, am I missing something?

E: A downside is that when picking a colour, the coordinates will still be relative to the original client, not to the area. So you can't easily use the colour picker to pick coordinates. I can see that turn into a pain.

I don't see what you'd be missing. Sets the client to the area we want everything to take place in as far as finding/mouse functions, and then uses it. Seems like a good fix to me.

I think this is a good idea, and keeps the amount of changes that need to happen to the include to a minimum.

From: shstiger2009
I don't see what you'd be missing. Sets the client to the area we want everything to take place in as far as finding/mouse functions, and then uses it. Seems like a good fix to me.

It's the best fix.. it's as good as it gets. Hopefully it allows shifting right and left too not just up and down.

Makes sense to me. The changes to the main screen cords will need to be reverted back if this is implemented.

Also, how would you incorporate this with the login and main screen differences? Just call it once in the login function and then again afterwards?

From: Silent SPY
Makes sense to me. The changes to the main screen cords will need to be reverted back if this is implemented.

Also, how would you incorporate this with the login and main screen differences? Just call it once in the login function and then again afterwards?

I think that's what ResetClientArea would do. I could be wrong though.

Sounds nice enough, I guess we can adapt - future written scripts will probably always incorporate offsets for the new client area.

Also will there be a default ClientArea for everyone so everyone would work under the same standard?

This is the best fix I think we could do, the banner at the top is 50 pixels btw, would you put this in SetupSRL or would we put it in our scripts?

Probably the setup SRL, no reason to have to add this into scripts imo..
this would also make non SMART users able to run fine with the dumb bar on top too

Also the login function in SRL will have to incorporate the function for it to get it working again as the Navbar isn't there in the login screen and the client area is still a bit off when logging in.

From: Wizzup?

E: A downside is that when picking a colour, the coordinates will still be relative to the original client, not to the area. So you can't easily use the colour picker to pick coordinates. I can see that turn into a pain.

Is it possible to just change the coordinate debug function of simba to display the corresponding values based on the client area set?
the idea is something like
writeln(ToStr(GetMousePos(x,y))
to
writeln(ToStr(GetMousePos(x - x_offset, y - y_offset))
I'm not experienced with the simba source so im not sure if the debug system can be changed that easily. (im assuming the x,y coordinate shown on the btm left of simba will also be wrong?)

If not i can create a simple calculator script that can print the adjusted coordinates, so users just have to input the values in it to be converted to the true values :p

From: speedster
Also the login function in SRL will have to incorporate the function for it to get it working again as the Navbar isn't there in the login screen and the client area is still a bit off when logging in.

That, and all srl functions that i can think of, will be automatically fixed with this method.

Awesome, this was exactly what I meant Wizzup :)


Edit. Can we add somekind of Define like DEF RS2, if so, then when we Crosshair and choose client we will use the Fixed Client side, this would make the scripting easier. I hop you huys get my point.


~Home

From: Home
Edit. Can we add somekind of Define like DEF RS2, if so, then when we Crosshair and choose client we will use the Fixed Client side, this would make the scripting easier. I hop you huys get my point.

Maybe we could just add a manual offset within the color picker, for users to specify, which you could put to 0, -50 for use with RS

From: putonajonny
Maybe we could just add a manual offset within the color picker, for users to specify, which you could put to 0, -50 for use with RS

That's true too. An excellent idea.

~Home

Thanks for the update

From: putonajonny
Maybe we could just add a manual offset within the color picker, for users to specify, which you could put to 0, -50 for use with RS

Yes the same for dtm editor as well (I normally use dtm editor to get coords). The only problem with that is if you're using it for a non rs game, the coords would be wrong. But I do like that option, maybe have an rs/nonrs toggle?

From: ashaman88
Yes the same for dtm editor as well (I normally use dtm editor to get coords). The only problem with that is if you're using it for a non rs game, the coords would be wrong. But I do like that option, maybe have an rs/nonrs toggle?

Yeah, that'd be a good option. A toggle between your offset and regular.

This seems like more of a band-aid then a fix. I agree it will work well for the immediate, but long term would you look at actually changing coordinates in SRL? As you mentioned with the color picking being off among other things, it would be nice to fix this correctly so all those work.

From: Bobarkinator
This seems like more of a band-aid then a fix. I agree it will work well for the immediate, but long term would you look at actually changing coordinates in SRL? As you mentioned with the color picking being off among other things, it would be nice to fix this correctly so all those work.

Not really if an offset option was put in. All it basically does is allow RS to work the same, and with no offset or anything, it's how it is right now.

From: Bobarkinator
This seems like more of a band-aid then a fix. I agree it will work well for the immediate, but long term would you look at actually changing coordinates in SRL? As you mentioned with the color picking being off among other things, it would be nice to fix this correctly so all those work.

This. It wouldn't take very long at all to go through and change the coordinates, and add that offset function Wizzup? spoke of in the other thread.

Dis regardless of this update, I'm not sure how Find* functions are working right now (no access to Simba).

Are you saying that the x and y values returned from a FindColor function will not be the actual location of the color?

From: abu_jwka
Dis regardless of this update, I'm not sure how Find* functions are working right now (no access to Simba).

Are you saying that the x and y values returned from a FindColor function will not be the actual location of the color?

No because if the function set the client to a specific area, then the specific area would have it's own coordinates starting from 0, 0.

From: shstiger2009
No because if the function set the client to a specific area, then the specific area would have it's own coordinates starting from 0, 0.

Nope.. He's shifting the pointer where Simba starts to read from upwards. The only functions that will not have proper coordinates would be the colour picker. All finder functions and mouse functions will be fine.

From: Bobarkinator
This seems like more of a band-aid then a fix. I agree it will work well for the immediate, but long term would you look at actually changing coordinates in SRL? As you mentioned with the color picking being off among other things, it would be nice to fix this correctly so all those work.

The problem is that the bar might change again, and again. And we really don't care about the bar, so we might as well ignore it. It's not really a band-aid fix but a rather nifty feature.

From: Brandon
Nope.. He's shifting the pointer where Simba starts to read from upwards. The only functions that will not have proper coordinates would be the colour picker. All finder functions and mouse functions will be fine.

Oh, I was under the impression that the function would basically "cut out" the Runescape area from Simba so that everything would stay the same.

From: shstiger2009
Oh, I was under the impression that the function would basically "cut out" the Runescape area from Simba so that everything would stay the same.

What it is basically doing is telling it to set client size within the selected window. So it kind of does "cut out" certain regions, but its removing the ones you want to ignore, like the stupid bar.

From: Wizzup?
The problem is that the bar might change again, and again. And we really don't care about the bar, so we might as well ignore it. It's not really a band-aid fix but a rather nifty feature.

^^ I agree with that

From: ashaman88
^^ I agree with that

Same, and the cool thing is, I'm sure scripts could utilize it ;)

I like the idea of the IfDef RS2 suggested earlier; to me the convince of it would outweigh the extra load time. Nonetheless, I'm appreciative of SetclientArea + ResetClientArea! :>

From: Wizzup?
The problem is that the bar might change again, and again. And we really don't care about the bar, so we might as well ignore it. It's not really a band-aid fix but a rather nifty feature.

The feature is nifty, but I still don't think it should be used as a permanent fix for this. Just add a const barheight and add it to all the hard coded coordinates

From: Bobarkinator
The feature is nifty, but I still don't think it should be used as a permanent fix for this. Just add a const barheight and add it to all the hard coded coordinates

So if the client changes again, that will have to be done again? The chances of it changing constantly are slim, but just in case.

I don't see any negatives with this new function…

From: shstiger2009
So if the client changes again, that will have to be done again? The chances of it changing constantly are slim, but just in case.

I don't see any negatives with this new function…

No, it's an alternative fix that he is talking about (one of several suggested).

Which the pixel length would just need adjusted if the bar ever changed again. They are both the same concept basically. One is just in SRL and one is native to Simba, or at least that's how I understand it.

Alright, let me clarify myself. I think this feature is great, being able to set an area of the client you have targeted is useful. But since the bar is part of the client I don't think we should just ignore it. It's not going to integrate with the color picker, or the status bar coordinates at the bottom of the user interface of simba. And gives a feeling of unprofessionalism. That's why I think we should change the hard coded coordinates.

From: Silent SPY
Which the pixel length would just need adjusted if the bar ever changed again. They are both the same concept basically. One is just in SRL and one is native to Simba, or at least that's how I understand it.

This is true… They are both the same idea, just different ways to correct.

From: Bobarkinator
Alright, let me clarify myself. I think this feature is great, being able to set an area of the client you have targeted is useful. But since the bar is part of the client I don't think we should just ignore it. It's not going to integrate with the color picker, or the status bar coordinates at the bottom of the user interface of simba. And gives a feeling of unprofessionalism. That's why I think we should change the hard coded coordinates.

I agree although this is much more work and also needs changes in all scripts.
I think there should be a way to integrate it with the color picker though, just add the coords relative to the area? show them both?

From: MasterCrimez
I agree although this is much more work and also needs changes in all scripts.
I think there should be a way to integrate it with the color picker though, just add the coords relative to the area? show them both?

Well the SetClientArea would be a function you would call in the script, and so the only way would be to put something in the interface to manually set it, similar to how there's a button that you can use to set the target

Thanks Wizzup that's pretty neat.

I'm begging to think a bar constant would work better… Sure this feature would still be nice to have, but it seems like an un-needed step in setting up scripts. If I've understood how it would work correctly. Wouldn't just having one constant to adjust be easier? Or shoot have a function that dynamically sizes the constant? That way even if they do change it in the login function we could just have a GetBarHeight, or something like that..

From: Silent SPY
I'm begging to think a bar constant would work better… Sure this feature would still be nice to have, but it seems like an un-needed step in setting up scripts. If I've understood how it would work correctly. Wouldn't just having one constant to adjust be easier? Or shoot have a function that dynamically sizes the constant? That way even if they do change it in the login function we could just have a GetBarHeight, or something like that..

What would you do if they placed the bar on the bottom? I don't mind the idea of someone changing all constants, but it'll still break ALL scripts. This is a timely solution and we can work towards making SRL not dependent on it over the course of time. In other words, SetClientArea and coordinates are both fine. But you'll only be able to fix SRL in a short time, not scripts. That's why we will (soon) also have SetClientArea. Then we can work towards making the scripts use coordinates with constants added to them. But to be fair, first come up with a real way to transform the coordinates. Rather than adding a constant, at least make it a function so you can change it all at once (and dynamically too).

Why would we need to change the client area in our scripts? I thought I saw someone say we would need to do that…why not just have it do it in setup srl and loginplayer or probably just loginplayer? And if you really want to use the actually coordinates without adjustment in your scripts (include the game bar), just setclientarea after calling the loginplayer function?

From: Wizzup?
What would you do if they placed the bar on the bottom? I don't mind the idea of someone changing all constants, but it'll still break ALL scripts. This is a timely solution and we can work towards making SRL not dependent on it over the course of time. In other words, SetClientArea and coordinates are both fine. But you'll only be able to fix SRL in a short time, not scripts. That's why we will (soon) also have SetClientArea. Then we can work towards making the scripts use coordinates with constants added to them. But to be fair, first come up with a real way to transform the coordinates. Rather than adding a constant, at least make it a function so you can change it all at once (and dynamically too).

As long as your working on making a better fix, then I'm all for this idea! It'll make things easier for the short term

Hey, how's it going? A progress report or finish expectation date would be nice ;)

From: Wizzup?
What would you do if they placed the bar on the bottom? I don't mind the idea of someone changing all constants, but it'll still break ALL scripts. This is a timely solution and we can work towards making SRL not dependent on it over the course of time. In other words, SetClientArea and coordinates are both fine. But you'll only be able to fix SRL in a short time, not scripts. That's why we will (soon) also have SetClientArea. Then we can work towards making the scripts use coordinates with constants added to them. But to be fair, first come up with a real way to transform the coordinates. Rather than adding a constant, at least make it a function so you can change it all at once (and dynamically too).

Is there a static list on constants somewhere? I'm working on a function but I don't really have the complete list of constants I'm sure… Guess I get to start hunting through the include…..

Edit: Start of function to return bar/black space.

Edit 2: Updated the second part to work more reliably.

program SetBarHeight;
//{$DEFINE SMART}
{$DEFINE SRL5}
{$i srl/srl.simba}

function BarHeight: Integer;
var
x, y, yOff, mX: Integer;
begin
  mX:= MSCX + 30;
 MMouse(MSCX+ 30, MSY1, 0, 0);
 //Writeln('moved mouse');
 if (GetColor(MSCX, MSY1) = 4605254) then
  begin
    Writeln('found color of box on login screen');
    yOff:= MSY1 + 3;
    while (GetColor(mX, yOff) = 0) do
    begin
      Inc(YOff);
      MMouse(mX, yOff, 0, 0);
      //Writeln('y offset is: ' + IntToStr(yOff - MSY1));
    end;
    Result:= yOff - MSY1 + 3;
    Writeln('y offset is: ' + IntToStr(yOff - MSY1 + 3));
    Exit;
  end;

  Writeln('Assuming we are past initial login.');
  Writeln('trying to determine nav bar offset at lobby screen');
  while not (FindColorTolerance(mX, yOff, 11119274, mX, yOff, mX, yOff, 2)) do
    begin
      Inc(YOff);
      MMouse(mX, yOff, 0, 0);
      //Writeln('y offset is: ' + IntToStr(yOff - MSY1));
    end;
  Writeln('y offset is: ' + IntToStr(yOff - MSY1 + 3));
  Result:= yOff - MSY1 + 3;
end;

begin
  (*Smart_Server := 72;
  Smart_Members := True;
  Smart_Signed := True;
  Smart_SuperDetail := False;*)
  SetupSRL;
  BarHeight;
end.

The second part, which applies to the lobby, wouldn't work in SMART for some reason. Feedback on why and what I could change would be awesome.

Okay, I've started work on this. It's done (untested at the moment, will test later) on Linux. I still have to do Windows and EIOS. They're both a bit harder, because they cache the width and the pointers they return are different from the ones in Linux. It's late and I don't want to make any mistakes, so I'm continuing tomorrow.

Progress here: https://github.com/MerlijnWajer/Simba/commits/setclientarea

E: I also need to do it for TRawTarget I believe. Next to Windows and TEIOS_Target

From: Wizzup?
Okay, I've started work on this. It's done (untested at the moment, will test later) on Linux. I still have to do Windows and EIOS. They're both a bit harder, because they cache the width and the pointers they return are different from the ones in Linux. It's late and I don't want to make any mistakes, so I'm continuing tomorrow.

Progress here: https://github.com/MerlijnWajer/Simba/commits/setclientarea

Sexy work Wizzup?. Can't wait for the windows fix as my debian partition isn't playing nice right now :/

will this also fix uptext and chatboxtext?

From: Arepirpi
will this also fix uptext and chatboxtext?

This should fix pretty much everything. As it offsets the client area as a whole. Some scripts might still be broken though depending on how this is implemented.

Linux, EIOS, Windows all implemented. I've briefly tested Linux and least that one seems to work. Left are TRawTarget and TBitmapTarget (both not too hard).

However, I'm a little worried about the following. If you call SetClientArea with a specific ``target'' active, it will only apply to that target. So if you call

bmp := BitmapFromClient(...);
SetTargetBitmap(bmp);

(0, 0) will really be the start of the bitmap. It doesn't look like it'll be an issue, though. Once you go back to the old client (using the proper method, so GetImageTarget / SetImageTarget), the SetClientArea will still be in effect.

Disclaimer: I have not tested the following code:

var cli, bmptar, bmp: integer;
begin
SetClientArea(...);
cli := GetImageTarget;

bmp := BitmapFromClient(...);
bmptar := SetTargetBitmap(bmp);
// stuff here
// setclientarea has no effect on the bitmap now (it does have effect on the mouse still)

SetImageTarget(cli);
// setclientarea should still be in effect here

FreeBitmap(bmp);
FreeTarget(bmptar);

end;

Im not sure if this has been suggested, but after this is done, what if Jagex identifies our weakness of the changing client size and uses it against us? By that, I mean change the client size by +/- 5 pixels each time you load up. I think it would be good to have a function that detects the bar size, or just have a constant added to all Y values. Yes, it would be a pain adding the constant to every single Y value in the include, but once this is done, should jagex change the client size again, all we have to do is change the constant value. Not sure if this makes sence, or if its been suggested already, but just an idea. Keep up the good work Devs!

This sounds like the best fix, it'd be really painful if we had to change every single coordinate.

From: Foooty
Im not sure if this has been suggested, but after this is done, what if Jagex identifies our weakness of the changing client size and uses it against us? By that, I mean change the client size by +/- 5 pixels each time you load up. I think it would be good to have a function that detects the bar size, or just have a constant added to all Y values. Yes, it would be a pain adding the constant to every single Y value in the include, but once this is done, should jagex change the client size again, all we have to do is change the constant value. Not sure if this makes sence, or if its been suggested already, but just an idea. Keep up the good work Devs!

There are a lot of weaknesses Jagex would abuse before changing the client dimensions, such as flagging accounts that load the client improperly(ie. current SMART) and accounts that press the TAB button often, for no reason at all.

Hmm.. I got: 6f3804e05efa0729b3c92b9095a69d67c8dbc291/ 2012-Jul-18 16:39:28

Doesn't have it yet. Guess we gotta wait still.

EDIT: :o Very nice! I see a script manager!

Hope the SetClientArea will be included in the SRL Login as the screen is a bit different in the login screen.

Also hoping for a default precise coordinate set for the ClientArea ;) - not for me but a lot of people will be asking.

Good Job on this. Do you guys have any ETA, when this will be implemented in SRL?


~Home

From: Home
Good Job on this. Do you guys have any ETA, when this will be implemented in SRL?


~Home

First I need to add the two targets that remain, then I will merge it in Simba-prev (0.99.x and Simba-master (1.0.x), and then everyone can start playing with it and iron out the bugs while we add support for SRL.

From: Wizzup?
First I need to add the two targets that remain, then I will merge it in Simba-prev (0.99.x and Simba-master (1.0.x), and then everyone can start playing with it and iron out the bugs while we add support for SRL.

Ok, thanks. Can't wait for it :)

~Home

:D!! Thank you, wizzup.. I've been stalking these threads for awhile, I can't wait until everything is operational again :)

Simba is my favorite program to bot with. (Shh! Don't tell the others!)

From: Hoard
:D!! Thank you, wizzup.. I've been stalking these threads for awhile, I can't wait until everything is operational again :)

Simba is my favorite program to bot with. (Shh! Don't tell the others!)

I second everything he just said ^_^

This Simba contains my initial work on SetClientArea: http://nala.villavu.com/downloads/simba-prev/2ebb523f66d402b5b7a81c19f13c4f47a1ffbac9/

Basic things work; at least on Linux. I have not tested Windows or EIOS at all. I plan to do so tomorrow (while I also complete the TRawTarget and TBitmapTarget), but I decided to put it here for everyone to play with already.

Note: SetClientArea only works when using SetEIOSTarget (Latest SMART can do this) or manually dragging the crosshair to a window.

Things you can test:

• GetClientDimensions(w, h) should return the same w, h after a call to SetClientArea(0, 0, w, h);
• MoveMouse, ClickMouse, FindColor, GetColor should all use the SetClientArea offset. With SetClientArea(40, 40, w, h) movemouse(0, 0) should actually move to (40, 40) and GetMousePos should return (0, 0) after the movemouse, even though the mouse is technically at (40, 40), at least for the human eye.

Meanwhile, thanks for the patience. I'm sure once this is all up we'll be back to botting normally again… At least until Jagex tries to play with us some more.

E: Actually, I just found out I missed a part in the EIOS implementation, so hold your horses on that one too, for now.

all of the linux links open to a tab full of symbols and questionmarks in diamonds. I'm sure i'm doing something wrong, I just don't know what… :(
Also thanks for all the work that you devs have put into this, it looks like it took awhile

From: Wizzup?
This Simba contains my initial work on SetClientArea: http://nala.villavu.com/downloads/simba-prev/2ebb523f66d402b5b7a81c19f13c4f47a1ffbac9/

Basic things work; at least on Linux. I have not tested Windows or EIOS at all. I plan to do so tomorrow (while I also complete the TRawTarget and TBitmapTarget), but I decided to put it here for everyone to play with already.

Note: SetClientArea only works when using SetEIOSTarget (Latest SMART can do this) or manually dragging the crosshair to a window.

Things you can test:

• GetClientDimensions(w, h) should return the same w, h after a call to SetClientArea(0, 0, w, h);
• MoveMouse, ClickMouse, FindColor, GetColor should all use the SetClientArea offset. With SetClientArea(40, 40, w, h) movemouse(0, 0) should actually move to (40, 40) and GetMousePos should return (0, 0) after the movemouse, even though the mouse is technically at (40, 40), at least for the human eye.

Meanwhile, thanks for the patience. I'm sure once this is all up we'll be back to botting normally again… At least until Jagex tries to play with us some more.

E: Actually, I just found out I missed a part in the EIOS implementation, so hold your horses on that one too, for now.

I tested the windows portion. And she works beautifully. Tested a few functions like MMouse, LoginPlayer (needs help after first screen), and OpenNpcBank. All worked perfectly. My test script also preceded to properly enter the pin, so it seems as though SRL is mostly? Working.


Test scripts I ran using Simba .99 with new plugins. I did not test SMART.

program test;
{$I SRL/SRL.Simba}
procedure DeclarePlayers;
begin
  HowManyPlayers := 1; // Set the number of players you are using
  NumberOfPlayers(HowManyPlayers); // Don't touch
  CurrentPlayer := 0; // This is the player to start with; the first player will always be 0

  Players[0].Name := ''; // Username
  Players[0].Pass := '';  // Password
  Players[0].Active := True;
end;
begin
  SetClientArea(0, 22, 763, 551);
  SetupSRL;
  DeclarePlayers;
  MMouse(MSX1, MSY1, 0, 0);
  LoginPlayer;
  exit;
end.

program test;
{$I SRL/SRL.Simba}
procedure DeclarePlayers;
begin
  HowManyPlayers := 1; // Set the number of players you are using
  NumberOfPlayers(HowManyPlayers); // Don't touch
  CurrentPlayer := 0; // This is the player to start with; the first player will always be 0

  Players[0].Name := ''; // Username
  Players[0].Pass := '';  // Password
  Players[0].Active := True;
end;
begin
  SetClientArea(0, 50, 763, 551);
  SetupSRL;
  DeclarePlayers;
  MMouse(MSCX, MSCY, 0, 0);
  OpenBankNpc;
  exit;
end.

I'll test more later but I have to leave.

EDIT: The mouse appears to behave quite strangely in the bank… It moves extremely fast and appears to be glitching at some points, but I'm guessing the SRL functions will just need some work. Also, item "punch hole" is still a very big issue, but not one that can be solved with Simba, only if SMART switches to openGL.


EDIT2: GetUpText also works correctly, as does ClickMouse. Haven't tested GetColor.

Nice work Wizzup?

Thanks for testing. I'll get an EIOS + RawTarget + BitmapTarget pushed out this evening. :)

Awesome work Wizz :) - It will take a few days after your release for others so they can fix the login screen bug and whatnot , but yeah quite nice. The new Smart works like a charm too (Need to see how it will be possible to run it under other graphical settings)

From: speedster
Awesome work Wizz :) - It will take a few days after your release for others so they can fix the login screen bug and whatnot , but yeah quite nice. The new Smart works like a charm too (Need to see how it will be possible to run it under other graphical settings)

Yeah, it would be sweet if BenLand could get that going so we wouldn't have to deal with Safe Mode anymore. He posted something about it in another thread but it wouldn't be able to be minimized or something like that. I wouldn't mind this at all really, I like making sure everything is always working good anyway so I never minimize my SMART.

Shtiger, he's working on that as far as I know.

@Everyone else, it's not a lot of work anymore but I keep getting distracted today. It'll be either tomorrow or monday (probably monday… :redface:).

No rush :) We know you'll get it working.

Nothing wrong with with taking time, besides it makes some of the lechers leave haha.

Does SMART 7.2 load runescape properly? I herad some stuff that smart didnt load RS properly, and that could flag accounts.

From: Ollybest
Nothing wrong with with taking time, besides it makes some of the lechers leave haha.

Couldn't have said it better :f:

From: Foooty
Does SMART 7.2 load runescape properly? I herad some stuff that smart didnt load RS properly, and that could flag accounts.

SMART 7.2 loads RS properly like it should. No worries like some of the older versions, although they weren't bad either. Benland and other said it COULD be detectable, like if Jagex were to put a new system in place for detection. But like I said, 7.2 loads it properly and it's fine. :)

Here are some functions that should eventually be added to SRL. It's not going to be as simple as setting the client (unless the bar's height isn't 50 pixels, like I have). A lot of functions are going to be broken since we do a lot of coordinate checks (which should be changed).

setupClient should be called in setupSRL, I think. That should take care of setting the client depending if your player is logged in or not. SetupInGameClient will need to be called somewhere in LoginPlayerToLobby, as well as SetupLoginClient in Logout. There are probably other functions as well, but it's a start.

procedure setupLoginClient();
var
  w, h: integer;
begin
  getClientDimensions(w, h); // get original width/height
  setClientArea(0, 22, w, h); // height of the black bar in the login screen
end;

procedure setupInGameClient();
var
  w, h: integer;
begin
  getClientDimensions(w, h); // get original width/height
  setClientArea(0, 50, w, h); // height of the navigation toolbar
end;

procedure setupClient();
begin
  setupInGameClient();

  // if player isn't logged in, setup client so we can login
  if ((not loggedIn()) and (not lobbyScreen())) then
    setupLoginClient();
end;   

E: Oh, and here's a LoggedIn function that will work with setupInGameClient().

function LoggedIn: Boolean;
var
  x, y: integer;
begin
  // white text on Report Abuse button
  result := findColor(x, y, 16777215, 465, 485, 475, 495);
end; 

I am sure that with time we will be able/ or you guys mostly since you do all the heavy lifting / to return to normal and identify any functions procedures which got broken with this update

New version: http://nala.villavu.com/downloads/simba-prev/b1e0e799ac527d1ce39e43691e5e43c4c906ac5d/

Changes:

• Support for EIOS (untested), RawTarget (partially tested), BitmapTarget (partially tested).
• Fixed GetColor for Windows. (GetColors didn't use ReturnData…)
• Split up the functions. There's now:
• MouseSetClientArea, MouseResetClientArea
• ImageSetClientArea, ImageResetClientArea

Example for images:

program new;
var bmp: integer;
var oldcli, bmpcli: integer;
var w, h: integer;
begin
  // Initial target size.
  getclientdimensions(w,h);
  writeln('w:', w, ' h:', h);

  // Shrink it a bit.
  imagesetclientarea(10, 10, w - 11, h - 11);

  // Shrinked size
  getclientdimensions(w,h);
  writeln('w:', w, ' h:', h);

  // Store current target
  oldcli:= GetImageTarget();
  writeln('oldcli: ', oldcli);

  // Create bitmap from current (shrinked size)
  bmp := BitmapFromClient(0, 0, w - 1, h -1);

  // Set bitmap as target
  SetTargetBitmap(bmp);

  // Bitmap target ref
  bmpcli := GetImageTarget();
  writeln('bmpcli: ', bmpcli);

  // Bitmap dimensions (same as shrinked)
  getclientdimensions(w,h);
  writeln('w:', w, ' h:', h);

  // Shrink (bitmap target!) size
  ImageSetClientArea(10, 10, 90, 90);

  // New shrinked size
  getclientdimensions(w,h);
  writeln('w:', w, ' h:', h);

  // Reset to bitmap size
  ImageResetClientArea;

  // Bitmap size
  getclientdimensions(w,h);
  writeln('w:', w, ' h:', h);

  // Reset old target
  SetImagetarget(oldcli);

  // Free target + bmp
  FreeTarget(bmpcli);
  FreeBitmap(bmp);

  // ``Shrinked a bit'' size
  getclientdimensions(w,h);
  writeln('w:', w, ' h:', h);

  // Reset this target as well
  ImageResetClientArea;

  // Normal size
  getclientdimensions(w,h);
  writeln('w:', w, ' h:', h);
end.

Important notes:

First of all, client area for image and mouse are now separate. You really don't want them to be different areas though. But I had to split them up for a simple reason: nesting image client areas would also touch the mouse area; and you don't want that, trust me.

So now they are separate. Just set the Mouse and Image area before login and after login (when the bar changes). Anything else should just work, as all operations like BitmapFromClient are already relative to the new Image area (even though _their_ ``clientarea'' is just 0,0)

E: This should work, theoretically&#8482;. I'll run more tests tomorrow.

Using the Simba version Wizzup? posted above me, plus the latest plugins from the 0.99 release thread, and my version of SRL (here), I am able to run scripts (at least login) normally in a browser (the SMART code in SRL doesn't work from what I'm testing).

My version of SRL includes:

• Client setting in SetupSRL. The scripter shouldn't have to call any of the Reset/SetClientArea functions.
• An out of range fix in SmartGetClientIDs.
• RSReady fix.

Obviously, I haven't had the chance to test all functions, but hopefully someone here can. Simply running a script will help a lot. Remember, SMART probably won't load (you'll get an error), so run a script in your browser. We'll work on fixing this as soon as we can.

Yes Coh3n I tested that. It works for the browser only. Most functions work. I didn't test all either but it's more than enough to bot.

Unfortunately though, that does not work for smart at all. I'm not sure if Wiz messed something up or not but when ran with smart, I had to divide everything by 2 (almost)!

So instead of 50, I made it 25. Instead of 22 I made it 13. This makes me wonder if something in Simba is messed up for smart because the bar is really 50 not 25. If I set it to 50 like you did, it will move 100 pixels. I even did BitmapFromClient and it cropped 100 pixels off the top even though it's set to 50.

Gunna look at Wiz's changes :P

EDIT:
After looking at the changes to Simba and testing it extensively with smart.. Do not use this with smart. It will not work at all. Even the mousesetclientarea will be completely off! For the imaging, it offsets incorrectly :S

EDIT2:
Figured out why.. The offsets are incremental! By this I mean anything that uses GetMousePos is literally screwed no matter what you do.

Example of working code but very bad:

var
  P: TPoint;
  TAB, X, Y: Integer;
begin
  {$IFDEF SMART}
    {$IFDEF SIMBAMAJOR980}
      Smart_Server := 72;
      Smart_Members := True;
      Smart_Signed := True;
      Smart_SuperDetail := False;
    {$ELSE}
      SRL_SixHourFix := True;
      Smart_FixSpeed := True;
    {$ENDIF}
  {$ENDIF}

  SetupSRL;

  Tab := TAB_MAGIC;
  MouseSetClientArea(0, 50, 765, 503);
  P:= Point((Tab - 21) mod 8 * 30 + RandomRange(527, 545), (Tab - 21) div 8 * 298 + RandomRange(177, 197));
  MoveMouse(P.X, P.Y);  //Uses MoveMouse.. This uses Smart's mouse directly!
  writeln(Point(X, Y));
end.

Example of good code but bad in the sense that it will NEVER work:

var
  P: TPoint;
  TAB, X, Y: Integer;
begin
  {$IFDEF SMART}
    {$IFDEF SIMBAMAJOR980}
      Smart_Server := 72;
      Smart_Members := True;
      Smart_Signed := True;
      Smart_SuperDetail := False;
    {$ELSE}
      SRL_SixHourFix := True;
      Smart_FixSpeed := True;
    {$ENDIF}
  {$ENDIF}

  SetupSRL;

  Tab := TAB_MAGIC;
  MouseSetClientArea(0, 50, 765, 503);
  P:= Point((Tab - 21) mod 8 * 30 + RandomRange(527, 545), (Tab - 21) div 8 * 298 + RandomRange(177, 197));
  MMouse(P.X, P.Y, 0, 0);  //Uses MMouse.. This circumvents Smart's Mouse with an intermediate function/wrapper. It uses GetMousePos then increments on that.
  writeln(Point(X, Y));
end.

See the difference yet? The difference is MMouse vs. MoveMouse. Literally all other functions are a wrapper of MMouse which is a wrapper of WindMouse which is intern a wrapper for MoveMouse. MMouse uses the current cursor position to figure out what it should do next. This is bad because it will incrementally move the mouse. Inother words if you specify an offset of 50, it will move 100. If you specify an offset of 22, it will move 44. It's double stepping.

Now I'm not sure why the Images are doing this but I know for sure GetMousePos is screwed up. I'll look into the images in the morning I'm tired right now.

P.S. It only does this for smart.. Dunno why.

From: Coh3n
Using the Simba version Wizzup? posted above me, plus the latest plugins from the 0.99 release thread, and my version of SRL (here), I am able to run scripts (at least login) normally in a browser (the SMART code in SRL doesn't work from what I'm testing).

My version of SRL includes:

• Client setting in SetupSRL. The scripter shouldn't have to call any of the Reset/SetClientArea functions.
• An out of range fix in SmartGetClientIDs.
• RSReady fix.

Obviously, I haven't had the chance to test all functions, but hopefully someone here can. Simply running a script will help a lot. Remember, SMART probably won't load (you'll get an error), so run a script in your browser. We'll work on fixing this as soon as we can.

I ran it on a private smelter script I have. Uses most things such as DTMs, TPAs, OpenBankNPC, MMouse, some ObjDTM include, UpText, and inventory counting. Seems to work okay once logged in, but…. I can't get it to log me in.

It will enter the player info and do the initial login process, after which it proceeds to sit there and spit this out:

Warning! You passed a wrong ye to a finder function: 500. The client has a height of 481, thus the ye is out of bounds. Setting the value to 480 (h-1) for now.

over and over again.

This happens right after it says

Welcome to Runescape.
Resetting game client - In-game client

Using Coh3n's SRL, and bleeding edge Simba (from two posts up). No Smart as it still refuses to load with the current state of SRL.

There are quite a few things that need the box areas/co-ord's re-doing.
Logout isn't working, finding the colour to know if your logged in isn't in the right co-ord and so on.
All because of the stupid bar they put at the top.
So anything that is done by a box/co-ord should be checked really.

From: Jakkle
There are quite a few things that need the box areas/co-ord's re-doing.
Logout isn't working, finding the colour to know if your logged in isn't in the right co-ord and so on.
All because of the stupid bar they put at the top.
So anything that is done by a box/co-ord should be checked really.

Did you try this with Coh3n's SRL?

The Setclient fix shifts the client, adjusting for these changes, I had quite a few functions run perfectly that all perform the "If not LoggedIn then Exit;" and they executed just fine.

I have not tested LogOut, so I can't comment on that right now, but most of the coords should be fixed with this.

Only thing I have noticed is the mouse acting extremely strange and jumpy…

From: Brandon
Yes Coh3n I tested that. It works for the browser only. Most functions work. I didn't test all either but it's more than enough to bot.

Unfortunately though, that does not work for smart at all. I'm not sure if Wiz messed something up or not but when ran with smart, I had to divide everything by 2 (almost)!

So instead of 50, I made it 25. Instead of 22 I made it 13. This makes me wonder if something in Simba is messed up for smart because the bar is really 50 not 25. If I set it to 50 like you did, it will move 100 pixels. I even did BitmapFromClient and it cropped 100 pixels off the top even though it's set to 50.

Gunna look at Wiz's changes :P

EDIT:
After looking at the changes to Simba and testing it extensively with smart.. Do not use this with smart. It will not work at all. Even the mousesetclientarea will be completely off! For the imaging, it offsets incorrectly :S

EDIT2:
Figured out why.. The offsets are incremental! By this I mean anything that uses GetMousePos is literally screwed no matter what you do.

Example of working code but very bad:

var
  P: TPoint;
  TAB, X, Y: Integer;
begin
  {$IFDEF SMART}
    {$IFDEF SIMBAMAJOR980}
      Smart_Server := 72;
      Smart_Members := True;
      Smart_Signed := True;
      Smart_SuperDetail := False;
    {$ELSE}
      SRL_SixHourFix := True;
      Smart_FixSpeed := True;
    {$ENDIF}
  {$ENDIF}

  SetupSRL;

  Tab := TAB_MAGIC;
  MouseSetClientArea(0, 50, 765, 503);
  P:= Point((Tab - 21) mod 8 * 30 + RandomRange(527, 545), (Tab - 21) div 8 * 298 + RandomRange(177, 197));
  MoveMouse(P.X, P.Y);  //Uses MoveMouse.. This uses Smart's mouse directly!
  writeln(Point(X, Y));
end.

Example of good code but bad in the sense that it will NEVER work:

var
  P: TPoint;
  TAB, X, Y: Integer;
begin
  {$IFDEF SMART}
    {$IFDEF SIMBAMAJOR980}
      Smart_Server := 72;
      Smart_Members := True;
      Smart_Signed := True;
      Smart_SuperDetail := False;
    {$ELSE}
      SRL_SixHourFix := True;
      Smart_FixSpeed := True;
    {$ENDIF}
  {$ENDIF}

  SetupSRL;

  Tab := TAB_MAGIC;
  MouseSetClientArea(0, 50, 765, 503);
  P:= Point((Tab - 21) mod 8 * 30 + RandomRange(527, 545), (Tab - 21) div 8 * 298 + RandomRange(177, 197));
  MMouse(P.X, P.Y, 0, 0);  //Uses MMouse.. This circumvents Smart's Mouse with an intermediate function/wrapper. It uses GetMousePos then increments on that.
  writeln(Point(X, Y));
end.

See the difference yet? The difference is MMouse vs. MoveMouse. Literally all other functions are a wrapper of MMouse which is a wrapper of WindMouse which is intern a wrapper for MoveMouse. MMouse uses the current cursor position to figure out what it should do next. This is bad because it will incrementally move the mouse. Inother words if you specify an offset of 50, it will move 100. If you specify an offset of 22, it will move 44. It's double stepping.

Now I'm not sure why the Images are doing this but I know for sure GetMousePos is screwed up. I'll look into the images in the morning I'm tired right now.

P.S. It only does this for smart.. Dunno why.

Well, I haven't tested EIOS yet, but will do in a bit. If you call WindMouse directly from SMART (I think SMART exports a WindMouse), don't. There's no EIOS method for that, so that is not hooked. Underlying functions must use GetMousePos and MoveMouse. I don't understand what you meant about it doubling though. I'll go and find out in a bit.

E: Also, if you use EIOS (Which you should!), then the MoveMouse should work just fine.

Alright, I may have found an issue with EIOS targets. The y-offset doesn't seem to work too well. I'm working on it and will report back.

E: Fixed. I had a local fix already but apparently the compilation failed and I didn't notice, so I kept staring at the code… :)

Try this one for EIOS. http://nala.villavu.com/downloads/simba-prev/999b7e9b7c92108debe3691692fa7306942d26c8/

My test script:

program EIOSTest;

procedure InitSmart();
var
  version: integer; //version of this record
  root, params: string; //Passed to SmartSetup
  width, height: integer; //Passed to SmartSetup
  initseq: string; //Passed to SmartSetup
  maxmem: integer; //Max JVM mem in MB, -1 is default
  jvmpath, useragent: string; //'' is the old defaults
begin
  version:= 0;
  root:= 'http://world15.runescape.com/';
  params:= 'plugin.js?param=o0,a1,m0';
  width:= 765;
  height:= 503;
  initseq:= 's';
  maxmem:= -1; //use SMART's default
  jvmpath:= ''; //use SMART's default
  //jvmpath:= '/opt/icedtea-bin-6.1.11.3/jre/lib/amd64/server/libjvm.so'; //use SMART's default
  useragent:= ''; //use SMART's default
  SetEIOSTarget('libsmart',IntToStr(version)+',"'+root+'","'+params+'",'+IntToStr(width)+','+IntToStr(height)+',"'+initseq+'",'+IntToStr(maxmem)+',"'+jvmpath+'","'+useragent+'"');
end;

procedure foo;
var bmp: integer;
var oldcli, bmpcli: integer;
var w, h: integer;
begin
  // Initial target size.
  getclientdimensions(w,h);
  writeln('w:', w, ' h:', h);

  // Shrink it a bit.
  imagesetclientarea(10, 10, w - 11, h - 11);

  // Shrinked size
  getclientdimensions(w,h);
  writeln('w:', w, ' h:', h);

  // Store current target
  oldcli:= GetImageTarget();
  writeln('oldcli: ', oldcli);

  // Create bitmap from current (shrinked size)
  bmp := BitmapFromClient(0, 0, w - 1, h -1);

  // Set bitmap as target
  SetTargetBitmap(bmp);

  // Bitmap target ref
  bmpcli := GetImageTarget();
  writeln('bmpcli: ', bmpcli);

  // Bitmap dimensions (same as shrinked)
  getclientdimensions(w,h);
  writeln('w:', w, ' h:', h);

  // Shrink (bitmap target!) size
  ImageSetClientArea(10, 10, 90, 90);

  // New shrinked size
  getclientdimensions(w,h);
  writeln('w:', w, ' h:', h);

  // Reset to bitmap size
  ImageResetClientArea;

  // Bitmap size
  getclientdimensions(w,h);
  writeln('w:', w, ' h:', h);

  // Reset old target
  SetImagetarget(oldcli);

  // Free target + bmp
  FreeTarget(bmpcli);
  FreeBitmap(bmp);

  // ``Shrinked a bit'' size
  getclientdimensions(w,h);
  writeln('w:', w, ' h:', h);

  // Reset this target as well
  ImageResetClientArea;

  // Normal size
  getclientdimensions(w,h);
  writeln('w:', w, ' h:', h);
end;

procedure bar;
  var bmp, w, h: integer;
begin
  getclientdimensions(w,h);
  writeln('w:', w, ' h:', h);
  imagesetclientarea(40, 40, w-1, h-1);
  getclientdimensions(w,h);
  writeln('w:', w, ' h:', h);
  bmp:=bitmapfromclient(0,0,w-1,h-1);
  savebitmap(bmp, 'hello.png');
  freebitmap(bmp);
  imageresetclientarea;
end;

procedure quux;
var w, h: integer;
begin
  getclientdimensions(w,h);
  writeln('w:', w, ' h:', h);
  mousesetclientarea(20, 20, w -1, h-1);
  movemouse(10, 10);
  mouseresetclientarea;
  wait(1000);
  movemouse(10, 10);
end;

begin
  InitSmart();
  //Now, all of Simba's functions use SMART as the target, no hacks.


  //foo;
  bar;
  //quux;
end.

The following code will make hte mouse JUMP to the magic tab, and jump south 200 pixels. MouseSetClientArea(0, 50….)

That 50 will make it jump 200 pixels on the Y axis (Yellow Box). Without it, the mouse will be 50 pixels less than where it's supposed to be (White Box). Basically it will move to the bar and then jump to the yellow box, move to the bar to try again and jump to the yellow box. If I modify that function to use MoveMouse instead, it works perfectly! So it's the GetMousePos that's messing it up.

Math behind it: GetMousepos is adding 50 pixels Incrementally (every call). MMouse calls it 3 times! 50 + (3 * 50) = 200. That's the same 200 pixels its jumping. It's just that something like this is bad:

//Simulate GetMousePos in the MMouse function..
var
   X, Y: Integer;
begin
  MouseSetClientArea(0, 50, 765, 552);
  GetMousePos(X, Y);
  writeln('X: ' + ToStr(X) + ' Y: ' + ToStr(Y));
  MoveMouse(X, Y);

  GetMousePos(X, Y);
  writeln('X: ' + ToStr(X) + ' Y: ' + ToStr(Y));
  MoveMouse(X, Y);

  GetMousePos(X, Y);
  writeln('X: ' + ToStr(X) + ' Y: ' + ToStr(Y));
  MoveMouse(X, Y);
end.

[BANANA]
Compiled successfully in 1123 ms.
SRL Compiled in 16 msec
Please Wait.. Smart Is Currently Loading..
X: 0 Y: 450
X: 0 Y: 550
X: 0 Y: 650
Successfully executed.
[/BANANA]

See without the 50 offset, GetMousePos would work fine and it would not incrementally jump/move the mouse. I can fix the mouse function myself but anyscript that does this is screwed. There are banking functions that do this too. If I do touch the mouse function, anything that isn't Smart/RS related will get screwed so that is the problem with this which is why I'm leaving it. Let someone else do that.

Function FoundBar: Boolean;
var
  Bar, X, Y: Integer;
begin
  Bar := BitmapFromString(8, 11, 'meJyr/PGn8scfBiRQCRYpeP0DiJD' +
        'FISIZ974BEbI4RCTmCgjxaMbJOFcDkVr6XIiI3+HPQOQ4/wyEAUcu' +
        '2z4CkZBdjZBdLRBJR86FiFgsfw9EyOZDRLSmvwEiZHGIiELXKyBCF' +
        'oeIiNc/ByJkcYgIXzEIIYtDRACmWWK1');

  Result := FindBitmapToleranceIn(Bar, X, Y, 117, 13, 171, 35, 10);
  BarShowing := Result;
  FreeBitmap(Bar);
end;

Procedure IgnoreBar;
begin
  ImageResetClientArea;
  If (FoundBar) then
    ImageSetClientArea(0, 50, 765, 503)
  else
    ImageSetClientArea(0, 22, 765, 503);
    //SetTargetArray(SmartImageArray + (765 * 22 * 4), 765, 503);
end;

var
  BMP: Integer;

begin
  {$IFDEF SMART}
    {$IFDEF SIMBAMAJOR980}
      Smart_Server := 72;
      Smart_Members := True;
      Smart_Signed := True;
      Smart_SuperDetail := False;
    {$ELSE}
      SRL_SixHourFix := True;
      Smart_FixSpeed := True;
    {$ENDIF}
  {$ENDIF}

  SetupSRL;
  IgnoreBar;
  MouseSetClientArea(0, 50, 765, 552);
  Gametab(TAB_MAGIC);  //Uses MMouse.

  //The below works fine now..
  BMP:= BitmapFromClient(0, 0, 765, 503);
  SaveBitmap(BMP, 'C:/Users/Brandon/Desktop/SmartBMP.bmp');
  FreeBitmap(BMP);
end.

From: Brandon


Math behind it: GetMousepos is adding 50 pixels Incrementally (every call). MMouse calls it 3 times! 50 + (3 * 50) = 200. That's the same 200 pixels its jumping.

Holy crap that sounds bad.

However isn't there like a way you can a simple variable in GetMousePos you can increment when called and when and only when that variable equals one, then add the 50 pixels…

So something like:

if (Called = 1) then
IncEx(y, 50)

So once it's called more than once, no 50 pixel increase. I'm pretty sure there's a more efficient maths function you can use to imitate that… it's mod if I remember correctly?

Very bad coding above but hopefully you get the point.

Brandon, you may be right. I need to think about this. I can easily remove this from GetMousePos again (I probably should) and then it's all fine. :)

Will post a new version soon.

From: abu_jwka
Holy crap that sounds bad.

However isn't there like a way you can a simple variable in GetMousePos you can increment when called and when and only when that variable equals one, then add the 50 pixels…

So something like:
Simba Code:
[LEFT]if (Called = 1) then
IncEx(y, 50)
[/LEFT]


So once it's called more than once, no 50 pixel increase. I'm pretty sure there's a more efficient maths function you can use to imitate that… it's mod if I remember correctly?

Very bad coding above but hopefully you get the point.

That would still require modding the actual mmouse function which I really really dont wanna touch because it might come back and bite me in the ass.

It's not the incrementing. It's the values passed to getmousepos which is a built in function exported from simba. It gets mouse pos which adds the 50 automatically. Mouse moves there, does that again and again so it implicitly increments. There is no way I can stop it from incrementing by that 50. Only way I can think of is probably {$IFNDEF SMART} GetMousePos {$ENDIF} or something like that. Other than that, Can't IncEx it because it's built in. Maybe just minus 50 from it every call if Smart is defined.

GetMousePos never had such behaviour before because the position itself was never offsetted. EDIT: Oh damn I never saw your post Wiz. :)

From: Brandon
That would still require modding the actual mmouse function which I really really dont wanna touch because it might come back and bite me in the ass.

It's not the incrementing. It's the values passed to getmousepos which is a built in function exported from simba. It gets mouse pos which adds the 50 automatically. Mouse moves there, does that again and again so it implicitly increments. There is no way I can stop it from incrementing by that 50. Only way I can think of is probably {$IFNDEF SMART} GetMousePos {$ENDIF} or something like that. Other than that, Can't IncEx it because it's built in. Maybe just minus 50 from it every call if Smart is defined.

OK now I understand. Luckily enough, no need to fear, Wizzup is here!

From: Wizzup?
Brandon, you may be right. I need to think about this. I can easily remove this from GetMousePos again (I probably should) and then it's all fine. :)

Will post a new version soon.

What was I thinking? It should be fixed now.

http://nala.villavu.com/downloads/simba-prev/63502dd4e42b6b2f2d7e7de3c26890d4ef26b0ef/

From: Silent SPY
Did you try this with Coh3n's SRL?

The Setclient fix shifts the client, adjusting for these changes, I had quite a few functions run perfectly that all perform the "If not LoggedIn then Exit;" and they executed just fine.

I have not tested LogOut, so I can't comment on that right now, but most of the coords should be fixed with this.

Only thing I have noticed is the mouse acting extremely strange and jumpy…

I'm just about to use Coh3n's version now with the newest Simba wizzup just posted. Fingers crossed all goes well :)

From: Wizzup?
What was I thinking? It should be fixed now.

http://nala.villavu.com/downloads/simba-prev/63502dd4e42b6b2f2d7e7de3c26890d4ef26b0ef/

LOL! Wizz! I think you're going to pull your hair out after this.. Another example:

var
  P: TPoint;
  TAB: Integer;

begin
  Tab:= TAB_MAGIC;
  P:= Point((Tab - 21) mod 8 * 30 + RandomRange(527, 545), (Tab - 21) div 8 * 298 + RandomRange(177, 197));

  Mouse(P.X, P.Y, 0, 0, MOUSE_MOVE);  //PERFECT! This now works as is. +1.
  GetMousePos(P.X, P.Y);      //Doesn't return absolute pos but who cares. Works as it's supposed to.
  HoldMouse(P.X, P.Y, MOUSE_LEFT);    //Nope.. Nada. Offsets mouse position.
  ReleaseMouse(P.X, P.Y, MOUSE_LEFT);  //Offsets too. Invisible though due to the previous call.
end.

Instead of incrementing with getmousepos, it now increments with hold and release mouse functions. I checked them both on the github and they both use MouseOffset. So rather than clicking in the specified position, it will move the mouse first then click at the offset.

A function such as this one (from the include, untouched) is messed up:

procedure ClickMouse2(button: variant);
var
  a,b,c : integer;
  iButton: Integer;
begin
  { Eventually, should be made to just use Integers }
  if (varType(button) = varBoolean) then
  begin
    if (button) then
      iButton := mouse_left
    else 
      iButton := mouse_right;
  end else
    iButton := button;
  
  if (iButton = mouse_move) then Exit; { we aren't actually clicking! }

  GetMousePos(b, c);

  HoldMouse(b, c, iButton);
  repeat
    Wait(20 + Random(30));
    a := a + 1;
  until (a > 4);
  GetMousePos(b, c);
  ReleaseMouse(b, c, iButton);
  Wait(50+Random(50));
end;

Lines 1045 and 1058: https://github.com/MerlijnWajer/Simba/blob/7981ca7668a38e273bfbbaefbd871636d732ce19/Units/MMLCore/iomanager.pas

LOL.. This bar is causing pain..

Again it's due to another mouse function using getmousepos which as you fixed is now relative to the client.. I'm not sure that clicking should be off-setted. It should just click at it's current position.

EDIT:

I could just reset client area in the clickmouse function. Dunno though. I think it'll be better to just fix the hold and release mouse. Only thing that should be off-setted for mouse functions is the moving.

Thanks, I'll look at it soon.

Try this, linear transform should be fixed. http://nala.villavu.com/downloads/simba-prev/220c4987680b92b9d045c36b2801f891d73e9d61/

From: Wizzup?
Try this, linear transform should be fixed. http://nala.villavu.com/downloads/simba-prev/220c4987680b92b9d045c36b2801f891d73e9d61/

Perfect! At least so far. If anything i'll let you know but so far everything is good.

From: Brandon
Perfect! At least so far. If anything i'll let you know but so far everything is good.

Does this mean we can get an official, working SRL soon?

From: Brandon
Perfect! At least so far. If anything i'll let you know but so far everything is good.

How did you get Smart functioning? It still refuses to initialize for me.

Edit: nvm, I'm a moron.

From: Wizzup?
Try this, linear transform should be fixed. http://nala.villavu.com/downloads/simba-prev/220c4987680b92b9d045c36b2801f891d73e9d61/

I've just installed this one and it keeps giving me

Program exception! 
Stacktrace:

Exception class: EAccessViolation
Message: Access violation
  $00000000
Simba Version: 1000

When closing simba (Every time).

From: Jakkle
I've just installed this one and it keeps giving me

Program exception! 
Stacktrace:

Exception class: EAccessViolation
Message: Access violation
  $00000000
Simba Version: 1000

When closing simba (Every time).

Simba Version: 1000? I don't think that simba-prev is Simba 1000

Well I clicked that link and downloaded this one
Installed it and clicked all the extensions I wanted to use then updated them and went to close Simba and it gave that error. I didn't try to run a script or anything.

From: Jakkle
Well I clicked that link and downloaded this one
Installed it and clicked all the extensions I wanted to use then updated them and went to close Simba and it gave that error. I didn't try to run a script or anything.

You can't use those extensions, you'll need the ones from the Simba .99 thread, and the newest Smart from the SMART 7.2 thread.

From: Silent SPY
You can't use those extensions, you'll need the ones from the Simba .99 thread, and the newest Smart from the SMART 7.2 thread.

I don't think you understand. All I did was install it and click the extensions I wanted, closed simba, then it gave the error. I didn't try to run a script or do anything else. I have done that with every simba I've had, never had that problem before.

From: Jakkle
Well I clicked that link and downloaded this one
Installed it and clicked all the extensions I wanted to use then updated them and went to close Simba and it gave that error. I didn't try to run a script or anything.

About: Simba shows 990 for me. Are you really really sure you're starting the right Simba?

From: Wizzup?
About: Simba shows 990 for me. Are you really really sure you're starting the right Simba?

Well I uninstalled that one now so I can't check that out but I could install it again and see.

Edit: I must of deleted the install file I used but I think I know what I might of done now tho come to think of it.
I have Buildbot: master on my bookmark bar which I clicked to see if it was the same download on there. I seen the same date and thought it was the same time but the one I downloaded must have been 1.0 :( sorry my bad.

From: Jakkle
Well I uninstalled that one now so I can't check that out but I could install it again and see.

Edit: I must of deleted the install file I used but I think I know what I might of done now tho come to think of it.
I have Buildbot: master on my bookmark bar which I clicked to see if it was the same download on there. I seen the same date and thought it was the same time but the one I downloaded must have been 1.0 :( sorry my bad.

Yeah, simba-prev is now 990 and master is 1000. :)

From: Wizzup?
Yeah, simba-prev is now 990 and master is 1000. :)

Yeah just seen that :duh: lol (simba-prev #30) is what I've downloaded and installed now. I should be able to get things sorted now :)

Oh and just wondering, why was 1000 giving me that error ? :p

From: Jakkle
Yeah just seen that :duh: lol (simba-prev #30) is what I've downloaded and installed now. I should be able to get things sorted now :)

Oh and just wondering, why was 1000 giving me that error ? :p

No idea, I'll have to investigate.

From: Jakkle
Yeah just seen that :duh: lol (simba-prev #30) is what I've downloaded and installed now. I should be able to get things sorted now :)

Oh and just wondering, why was 1000 giving me that error ? :p

Wait do you have custom builds of it yourself? That's crazy…

Wizzup did you push .991 to the updaters? Just curious :redface:

I'm so confused, is .991 out yet?
If so, why isn't it on the home page?

Be patient,
if it's "more a tomorrow kinda thing" then he'll have a reason for delaying.

Things are done when they're done, not when people want them to be done.

From: klamse
I'm so confused, is .991 out yet?
If so, why isn't it on the home page?

Because it isn't out yet, at least not officially and won't be until SRL is updated as well. At least that's what I believe.

From: Silent SPY
Because it isn't out yet, at least not officially and won't be until SRL is updated as well. At least that's what I believe.

Indeed, but i thought i read somewhere that SRL was updated a few hours ago though.

From: satkan
Indeed, but i thought i read somewhere that SRL was updated a few hours ago though.

Err, it was by that point, I was misinformed.