SRL Archive - SRL Suggestions

{*********************************************************************************
function RestrictLine(Xi, Yi, Xc, Yc, Slope: Integer; RS, Top: Boolean): Boolean;
By: Main_Ftw, i luffs yeww
Description: Check if a point has passed a line.
Xi, Yi: Imput X and Y value.
Xc, Yc: Center of the line, the origin: Mmcx, Mmcy...etc
Slope: slope of the line, 0 to 1000.
Rs: Are you using it in runescape? This take cares of the inverted rs coordinate.
Top: Is the restricted area Above or under the line.
Example:
  Top:=true;         

|-Restricted/-----|     
|--------------/------|
|-------------/-------|
|------------/--------|
|-----------/---------|
|----------/----------|
|---------/-----------|
|--------/------------|

Top:=false;

|------------/---------|     
|-----------/----------|
|----------/-----------|
|---------/------------|
|--------/-------------|
|-------/--------------|
|------/---------------|
|-----/-Restricted-|
Example:
RestrictLine(0, 0, 50, 50, 1, true, true):
- This will result in true, because the input point (0,0) is in the restricted
  area which is above line with slope of 1 at the point (50,50).
RestrictLine(0, 0, 50, 50, 1, true, false):
- This will result iin true, because the input point (0,0) is not in the restricted
  area which is below line with slope of 1 at the point (50,50).
**********************************************************************************}
function RestrictLine(Xi, Yi, Xc, Yc, Slope: Integer; RS, Top: Boolean): Boolean;
var
  Y: Integer;
begin
  Y := -1 * slope * (Xi - Xc) + Yc;
  if(Top)then
    Result := not(Yi > Y)
  else
    Result := not(Yi < Y);
  if(RS)then
    Result := not(Result);
end;

This work similar to Rs_OnMiniMap, except it makes sure if a point is above (top=false) or under (top=true) a line.



I couldn't find a function like this the other day, so I made one. Please tell me if this is already made.

*Note*
(1) Watch out for the compass, because slope of a line at 60 degree is same as -120 degrees.
(2) It takes care of rs's inverted y axis. The function's line is draw in regular cartesian coordinate, so set rs to true to take care of the point in rs's coordinate system.

function RestrictLine(Xi, Yi, Xc, Yc, Slope: Integer; RS, Top: Boolean): Boolean;
var
  Y: Integer;
begin
  Y := -1 * Slope * (Xi - Xc) + Yc;
  if(Top)then
    Result := not(Yi > Y)
  else
    Result := not(Yi < Y);
  if(RS)then
    Result := not(Result);
end;

I think that can be shortened even more, actually. I just can't think right now.

lol added, ty.

To anyone who's bored, I think it can be shortened even more to something like

function RestrictLine(Xi, Yi, Xc, Yc, Slope: Integer; RS, Top: Boolean): Boolean;
begin
  Result := Boolean(Integer(RS) * (Integer(Top) * (Yi < (-1 * Slope * (Xi - Xc) + Yc))));
end;

From: i luffs yeww
To anyone who's bored, I think it can be shortened even more to something like

function RestrictLine(Xi, Yi, Xc, Yc, Slope: Integer; RS, Top: Boolean): Boolean;
begin
  Result := Boolean(Integer(RS) * (Integer(Top) * (Yi < (-1 * Slope * (Xi - Xc) + Yc))));
end;

No. This is just horrible… :p

Please, readable code without too much casting hacks… ;)

:p So the other one I posted would be better?

Looks fine. :)

I don't see any use for this in SRL core. Besides, it would be possible to just use FilterPointsPie or since it's possible to reduce this to one line makes it kinda pointless for a code wrapper to have to be compiled for every single script. Maybe I missed something :-P

I think its a bit easier to use than FilterPointsPie, because the new members aren't use to tpas…etc

Also this results a boolean:) and this can be used with slope of the x axis in the minimap.

Slope:=round((sine(round(Rs_GetCompassAngleDegrees)))/(0.001+cose(round(Rs_GetCompassAngleDegrees))));

P.S I remember you were looking for something like this :)

From: Main_Ftw
I think its a bit easier to use than FilterPointsPie, because the new members aren't use to tpas…etc

Also this results a boolean:) and this can be used with slope of the x axis in the minimap.

Slope:=round((sine(round(Rs_GetCompassAngleDegrees)))/(0.001+cose(round(Rs_GetCompassAngleDegrees))));

P.S I remember you were looking for something like this :)

I don't see this being widely used enough to be included in SRL core. The thing I was looking for was a lot different in that it turns a TPA into a TPA that is only the points that are on a line, and that too wouldn't be useful in core.

In the past when checking if a point is in a certain area of the minimap I've just used FilterPointsPie… there's also the way of using Distance+ArcTan2 (angle between two points) + InRange (which is essentially filterpointspie watered down lol) to check for these types of things.

Personally I can't see a use for knowing if something is below or above a line with a certain slope, I can see a use for knowing if something is in a certain area of the MM but there are other ways of doing that.

The real reason is there is already too many functions in SRL that are not used at all… compile time for SRL is 8 seconds on my 524mb ram 32bit windows XP. Which could easily be cut down to 2 seconds if we removed all the unused parts of SRL.

From: IceFire908
I don't see this being widely used enough to be included in SRL core. The thing I was looking for was a lot different in that it turns a TPA into a TPA that is only the points that are on a line, and that too wouldn't be useful in core.

In the past when checking if a point is in a certain area of the minimap I've just used FilterPointsPie… there's also the way of using Distance+ArcTan2 (angle between two points) + InRange (which is essentially filterpointspie watered down lol) to check for these types of things.

Personally I can't see a use for knowing if something is below or above a line with a certain slope, I can see a use for knowing if something is in a certain area of the MM but there are other ways of doing that.

The real reason is there is already too many functions in SRL that are not used at all… compile time for SRL is 8 seconds on my 524mb ram 32bit windows XP. Which could easily be cut down to 2 seconds if we removed all the unused parts of SRL.

… Just because SCAR compiles SRL slow on your machine doesn't mean it shouldn't be in SRL!
It compiles under 500ms (Simba) on my machine.

I think it's probably a good function for the Math include.

From: Wizzup?
… Just because SCAR compiles SRL slow on your machine doesn't mean it shouldn't be in SRL!
It compiles under 500ms (Simba) on my machine.

I think it's probably a good function for the Math include.

Compile time is more or less insignificant, I think you missed the rest of my post.

From: IceFire908
Compile time is more or less insignificant, I think you missed the rest of my post.

The real reason is …?

"The real reason is there is already too many functions in SRL that are not used at all" - IceFire908.

From: i luffs yeww
"The real reason is there is already too many functions in SRL that are not used at all" - IceFire908.

That alone isn't a problem at all. His problem with that is that SRL compiles slow on SCAR.

@ Ice

Compile doesn't slow down function speeds thou, only ram. While It is true that taking up a lot of ram is a bad thing, but there are plenty of other functions that is not used.

You gotta trust me on this, but I use a different include for my auto pker, I removed about 80% of the srl function and there are no difference.

Wizzup?: I was just saying that he literally said in his post that the reason was "there is already too many functions in SRL that are not used at all." It made more sense to me earlier. :p

I may have used the words "The real reason is" but you also used the words "Just because" when I had several other good points which you decided to ignore for whatever reason.

I'm just saying that that's what you said. :)

From: IceFire908
I may have used the words "The real reason is" but you also used the words "Just because" when I had several other good points which you decided to ignore for whatever reason.

No, I didn't decide to ignore them. I decided to make a remark directly about that (IMO) ignorant statement you made.

From: IceFire908
I don't see this being widely used enough to be included in SRL core. The thing I was looking for was a lot different in that it turns a TPA into a TPA that is only the points that are on a line, and that too wouldn't be useful in core.

You can indeed use FilterPointsPie for this.

From: IceFire908

Personally I can't see a use for knowing if something is below or above a line with a certain slope, I can see a use for knowing if something is in a certain area of the MM but there are other ways of doing that.

I guess this is your only other reason…?
Anyway, I can see certainly see some use for this function. In fact, I wonder why someone hasn't written it a long time ago. I've always liked using some maths in my script which IMO often gave it that extra little boost which made them more reliable. Dividing the minimap into other areas is just as useful as FilterPointsPie IMO. Remember that you can also use several lines to create other polygons. This would help if you wanted an easy way to filter an abstract area of points.

What I would like to see of this function is one takes a TPA and then applies the same filter, but with a boolean. (True for points IN, False for points OUT)

We could put it in WizzyPlugin. Then IceFire will be happy too, as his SRL will compile in no less than 8 seconds still!

i think it would be nifty if you could specify more than one slope. I however am thinking more of vectors i think than slopes. You define a starting point, then create a vector and the next vector would start from the last. Then the last one would link back to the first which would then allow you to make shapes rather than just slopes where if you wanted to cordon off a slice of the minimap with this function you'd need to do it twice then get rid of the section on the opposite side of the map that you didn't want.

But what happen if one line is above the other? then the second line is blocked.

Or you can just use it twice :p

From: Wizzup?
No, I didn't decide to ignore them. I decided to make a remark directly about that (IMO) ignorant statement you made.

When everything you read sounds ignorant it's probably a good idea to reevaluate how you interpret everything you read.

From: Wizzup?
You can indeed use FilterPointsPie for this.

FilterPointsLine restricts the width of the slice to be no more or less than 1 pixel in width, while as FilterPointsPie literally gives you a slice of pie that is anywhere from 0 to 4 pixels in width in different parts when using it in the same way FilterPointsLine is used. I think you're talking about FilterPointsPie vs RestrictLine though which as I said isn't very pracitcal to use, the minimap rotates and moves in out… it's much more logical to use pie slices instead of a slope line… except maybe in some super rare case that I can't think of which is why I suggested it doesn't belong in core, after a while you end up with a lot of stuff and it increases compile time, so yea?

From: Wizzup?
I guess this is your only other reason…?
Anyway, I can see certainly see some use for this function. In fact, I wonder why someone hasn't written it a long time ago. I've always liked using some maths in my script which IMO often gave it that extra little boost which made them more reliable. Dividing the minimap into other areas is just as useful as FilterPointsPie IMO. Remember that you can also use several lines to create other polygons. This would help if you wanted an easy way to filter an abstract area of points.

What I would like to see of this function is one takes a TPA and then applies the same filter, but with a boolean. (True for points IN, False for points OUT)

We could put it in WizzyPlugin. Then IceFire will be happy too, as his SRL will compile in no less than 8 seconds still!

It's a combination of reasons…
I can't think of any practical reasons to include this in core, because it would be used rarely, if at all.

From: IceFire908
It's a combination of reasons…
I can't think of any practical reasons to include this in core, because it would be used rarely, if at all.

I just gave some possible ways it can be used… And since we both agree the functions do an entirely different thing, and only in some cases can achieve the same, there's no reason not to add it.

From: Wizzup?
I just gave some possible ways it can be used… And since we both agree the functions do an entirely different thing, and only in some cases can achieve the same, there's no reason not to add it.

Win. :p

~RM

Ty for the "feedbacks" :p