SRL Archive - SRL Updates & Announcements

Thanks to this cool guy @core and @Hobbit;

• Randomness added to the mouse will now randomly add OR subtract the amount, previously randomness only added. - reverted.
• Changes to increase the performance of the mouse function by 40.000545453450606%.
• Radial walk should now function correctly
• Added compass directions to RadialWalkEx, ex. 'n', 's', etc.

Note: This affects both SRL5 and OSR-SRL

Randomness added to the mouse will now randomly add OR subtract the amount, previously randomness only added.

About time! Great work all of you!

Good to hear I saw a couple people said radial didn't work

Wonderful! Finally a walking method that will work for RS07!

Great work!

From: Ollybest
Thanks to this cool guy @core and @Hobbit;

• Randomness added to the mouse will now randomly add OR subtract the amount, previously randomness only added.
• Changes to increase the performance of the mouse function by 40.000545453450606%.
• Radial walk should now function correctly
• Added compass directions to RadialWalkEx, ex. 'n', 's', etc.

Note: This affects both SRL5 and OSR-SRL

Wow finally I have waited to test this out! SPS just sucks! And so do DTMS!

The new mouse change has ruined my scripts. Is there anyway I can use the mouse function prior to this update? I do not have it saved anywhere as SRL automatically updated.

From: cycrosism
The new mouse change has ruined my scripts. Is there anyway I can use the mouse function prior to this update? I do not have it saved anywhere as SRL automatically updated.

I was surprised that the pull request got accepted for this exact reason not only users scripts but also some of SRL was broken.

Wow, yeah, that mouse matter has been around for years now and we have always settled on it being too much a hassle to change all scripts if we do this..
Why was it pulled now?

Maybe @Hobbit can enlighten us :p

Yeah, I remember being part of a discussion a while ago about whether or not we should do this, and the consensus was "no, it'll break too many things."

Any bitmap clicking procedures/functions are now broken? :p

No wonder I was getting mouse errors on all my scripts! Uhh!

From: Ollybest
I was surprised that the pull request got accepted for this exact reason not only users scripts but also some of SRL was broken.

How

From: Zyt3x
Wow, yeah, that mouse matter has been around for years now and we have always settled on it being too much a hassle to change all scripts if we do this..
Why was it pulled now?

Where

From: Rules of Joe
No wonder I was getting mouse errors on all my scripts! Uhh!

This wouldn't actually cause any errors… Purely a functional thing.

From: Hobbit
How



Where



This wouldn't actually cause any errors… Purely a functional thing.

https://github.com/SRL/SRL-5/commit/0497c973f11c4d5b17b39d7c98258aaec48113b5

for years mouse randomness only added, like Zyt3x was saying it was always kept like this because it would be a huge hassle because it would break alot of things.

From: Ollybest
https://github.com/SRL/SRL-5/commit/0497c973f11c4d5b17b39d7c98258aaec48113b5

for years mouse randomness only added, like Zyt3x was saying it was always kept like this because it would be a huge hassle because it would break alot of things.

I know which commit it is, I commited it.

How exactly does it break things?

Ex:
Mouse(x,y,6,6, mouse_Left)
This will still work the same, 6 is still the total amount of randomness added to the point, however it actually makes sense now because its possibly +3 or -3, but still same amount of randomness.

From: Hobbit
I know which commit it is, I commited it.

How exactly does it break things?

Ex:
Mouse(x,y,6,6, mouse_Left)
This will still work the same, 6 is still the total amount of randomness added to the point, however it actually makes sense now because its possibly +3 or -3, but still same amount of randomness.

Yeah it makes sense now but thing still need changing mostly in peoples scripts, such as if a bitmap is returned it finds the top left point, and now mouse(x, y, 15, 15, MOUSE_LEFT) could possibly click off the bitmap, an example in SRL was that closeBank was broken, its fixed now though but im sure there's more.

Then revert it? And if you thought it was such an issue why didn't you bring it up when you posted this thread.
Still not an issue IMO but do whatever.

I did this in SRL6 effectively letting the scripter decide whether to add or subtract the randomness, but allowing for either one. This is helpful, and nearly necessary as it allows for the scripter to specify in which direction to add randomness.

function TPoint.rand(xx, yy : Integer): TPoint;
var
  nx, ny, rx, ry: integer;
begin
  nx := xx div abs(xx);   //div by self to determine positive or negative
  ny := yy div abs(yy);

  rx := random(xx) * nx;
  ry := random(yy) * ny;

  result.x := x + rx;
  result.y := y + ry;
end; 

I know I've been gone for a bit, but this particular change probably could have waited until SRL6 is released.

Everything else seems to be all well though. Nice job everyone! :)

From: Hobbit
Then revert it? And if you thought it was such an issue why didn't you bring it up when you posted this thread.
Still not an issue IMO but do whatever.

When I posted this I didn't really think that it could break stuff until I started seeing complaints about closeBank not working, and IMO it is far better as it actually makes sense but people need to be warned that this update happened.

From: Ollybest
When I posted this I didn't really think that it could break stuff until I started seeing complaints about closeBank not working, and IMO it is far better as it actually makes sense but people need to be warned that this update happened.

SRL5 as a whole will need to be adjusted then, as well as ALL scripts. Is this really worth the effort considering people will have do update EVERYTHING again once SRL6 is pushed out? I'm not sure of SRL6's exact status as I've been away, but I can't imagine it's far off; especially now that I'll be back around ;)

From: NCDS
SRL5 as a whole will need to be adjusted then, as well as ALL scripts. Is this really worth the effort considering people will have do update EVERYTHING again once SRL6 is pushed out? I'm not sure of SRL6's exact status as I've been away, but I can't imagine it's far off; especially now that I'll be back around ;)

Well its up to hobbit or a srl dev to make the decision on that :p, but now your back around get that mapwalk finished!

Could we please get rid of this change and bring back the good mouse procedure? The new one is just awful. Since I have started the mouse procedure was always the randomness added on, which was good. Because for bitmaps (Which I use heavily in my scripts) it adds on from the very top left of the bitmap. If it takes randomness OFF, then it is going to completely miss the bitmap. I was wondering why the hell my script kept missing the bitmap when I realised that it wasn't my script, it was something in SRL that had broken my scripts.

Please change it back.

None of my scripts required updating, closebank was the only thing not working

Bank update shouldn't need to be reverted, makes more sense now also.

[github=SRL-5]62403b5e51af07d58c396e8c71593f934491f352[/github]

@Hobbit It is causing Errors Because P07Incude is having MMouse Errors and I looked through the code and doesnt look wrong!

Thank you for reversing the change done to Mouse

Just so we know, are we using +- or just + from here on out? Everything I ever wrote was based on only adding, so everything I have will break because I added the - myself, and ALOT of srl5 stuff relies on it being only + because it uses top left corner and max horizontal/vertical difference,

Maybe we need two mouse functions? Just different names, but thats complicate things so whatever, IMO only adding is a better way to work with,

Just wanted to know what the final method will be?

It's reverted and is currently (Hobbit commited the revert) ONLY ADDING. :)

It appears that there is more variability in SRL 6, so keep a good eye out.

Edit: Can I get a verify on this (was told it was still causing errors)
https://github.com/SRL/SRL-5/pull/166

@OllyBest

I feel that the fact that the mouse change was reverted should be reflected in the OP to prevent further confusion.

From: core
Hey, thanks!

I'm still of the opinion that randomness should be an ellipse with the random modifiers acting as the radii of that ellipse. Is there any way to make this not be directional and have this behavior instead? If I say myPoint.rand(5, 10), I'd fully expect there to be anywhere from myPoint.x - 5 to myPoint.x + 5, and myPoint.y - 10 to myPoint.y + 10 ranges, does that go against everyone else's expected behavior of the idea? (I know this is against the current behavior of SRL5)

I like this ellipse idea! But I think if and/or when we change it, it should be done in SRL6 :)

From: core
Hey, thanks!

I'm still of the opinion that randomness should be an ellipse with the random modifiers acting as the radii of that ellipse. Is there any way to make this not be directional and have this behavior instead? If I say myPoint.rand(5, 10), I'd fully expect there to be anywhere from myPoint.x - 5 to myPoint.x + 5, and myPoint.y - 10 to myPoint.y + 10 ranges, does that go against everyone else's expected behavior of the idea? (I know this is against the current behavior of SRL5)

I'm in no way opposed to that, and it's surely easy enough to make a mouse 'wrapper' of sorts that does just that. However, many instances call for randomness in a specific direction, so we clearly can't remove that functionality.

From: core
Hey, thanks!

I'm still of the opinion that randomness should be an ellipse with the random modifiers acting as the radii of that ellipse. Is there any way to make this not be directional and have this behavior instead? If I say myPoint.rand(5, 10), I'd fully expect there to be anywhere from myPoint.x - 5 to myPoint.x + 5, and myPoint.y - 10 to myPoint.y + 10 ranges, does that go against everyone else's expected behavior of the idea? (I know this is against the current behavior of SRL5)

We already have mouseEllipse btw, would be nice to use gaussian in it though.

From: Ollybest
When I posted this I didn't really think that it could break stuff until I started seeing complaints about closeBank not working, and IMO it is far better as it actually makes sense but people need to be warned that this update happened.

I think atm, the only thing that is breaking CloseBank is that the area of the cross icon is set wrong. the icon is a square of about 10x10 pixels, but the line that makes the click and sets the coordinates looks like this after the latest update:

 MouseBox(484, 30, 493, 50, mouse_left);

(10x20 box??)

the combination that works for me is this:

 MouseBox(484, 30, 493, 40, mouse_left);

please change it with the next update

From: core
Yep! I meant for SRL6.


That works for me, I can definitely see the need for directional and non-directional randomness. I'd personally still like it to be done as part of TPoint though, since there may be other uses besides mouse?


That would be fun.

var
gX, gY: Integer;
// get a gaussian pt in a circle:
Gauss_Point(MMCX, MMCY, 0, math_2PI, MMX2-MMCX, gX, gY);
WriteLn(Format("gX, gY -> %d, %d", gX, gY);

in math.simba.. seems like it would be quite easy.

From: l6bustank
I think atm, the only thing that is breaking CloseBank is that the area of the cross icon is set wrong. the icon is a square of about 10x10 pixels, but the line that makes the click and sets the coordinates looks like this after the latest update:

 MouseBox(484, 30, 493, 50, mouse_left);

(10x20 box??)

the combination that works for me is this:

 MouseBox(484, 30, 493, 40, mouse_left);

please change it with the next update

It's already been changed - it's just awaiting a pull request on git, and then from there it will be addded to the auto updater.

oh, nice to hear :)

From: core
FTFY:p

But in all seriousness, thanks! My first mention!

By the sounds of it you deserve a second ;)

@core;