My views on Reflection Member Apps

I don't know as I totally agree with reflection apps. AFAIK it's not technically part of SRL, and it is so much easier than color.

An example: (This is taken from a recent members app)

SCAR Code:

function findFishingSpot: boolean;
var
  FP: tnpc;
begin
if (FindNPC('Fishing Spot', FP)) then
  begin
    if(TileOnMS(Fp.tile, 10))then
    begin
      result := true;
    end else
    begin
      result := false;
    end;
  end;
end;

I'm not familiar with Reflection so I can't be sure but this function can be done in 2 lines.
So this would be a Reflection FindFishingSpot function:

SCAR Code:

function findFishingSpot: boolean;
var
  FP: tnpc;
begin
  if (FindNPC('Fishing Spot', FP)) then
    Result := (TileOnMS(Fp.tile, 10));
end;

// if not that, then this:

function findFishingSpot: boolean;
var
  FP: tnpc;
begin
  if (FindNPC('Fishing Spot', FP)) then
    if(TileOnMS(Fp.tile, 10))then
      result := true;
end;

As simple as 2 or 3 lines apparently either way.

This would be color: (Taken from another member)

SCAR Code:

Function FindFish(var Spot: TPoint; x1, y1, x2, y2: Integer) : Boolean;
Var
  CTS, I: Integer;
  Spott: TPointArray;
  ATPA: Array of TPointArray;
begin
  CTS := GetColorToleranceSpeed;
  ColorToleranceSpeed(2);
  SetColorSpeed2Modifiers(0.10, 0.24);
  FindColorsSpiralTolerance(MSCX, MSCY, Spott, 11972264 , x1, y1, x2, y2, 13);
  //DebugTPA(Spott, 'lll');
  If Length(Spott) < 1 then
  begin
    Write('Error, couldn''t find fishing spot!');
    Result := False;
    exit;
  end;
  ColorToleranceSpeed(CTS);
  ATPA := TPAToATPAEx(Spott, 6, 6);
  For I := 0 to High(ATPA) do
  begin
    MiddleTPAEx(ATPA[i], Spot.x, Spot.y);
    If not (distance(Spot.x, Spot.y, MSCX, MSCY) > 200)then
    begin
      Result := True;
      Break;
    end;
  end;
end;

Granted, this could be done in less lines as well, it still seems to take much more effort.

I don't mean to attack or offend anyone, I'm just curious to read others thoughts on this. :o


To Clarify: I have nothing against reflection, or people that use it at all.



*Waits for Method to post*

i cant say any thing on how applications should be done(seeing as i havnt applied for my recent membership) but i find reflection to be lazy, if you make a script 100% reflection. but if you use reflection correctly on something understandably difficult, and use color failsafes or vis-versa i would be alright

Quote:

---

Originally Posted by akwardsaw

i cant say any thing on how applications should be done(seeing as i havnt applied for my recent membership) but i find reflection to be lazy, if you make a script 100% reflection. but if you use reflection correctly on something understandably difficult, and use color failsafes or vis-versa i would be alright

---

And I agree, if I saw a reflection app, as long as it had a good usage of Scar and SRL commands, it would be totally fine. But to me it seems almost like it's becoming sort of "the easy way in".

Quote:

---

Originally Posted by akwardsaw

i cant say any thing on how applications should be done(seeing as i havnt applied for my recent membership) but i find reflection to be lazy, if you make a script 100% reflection. but if you use reflection correctly on something understandably difficult, and use color failsafes or vis-versa i would be alright

---

I do not think its lazy. It is just a different way of doing something.

Yup, and sometimes even better.
Although what I think you have to know as SRL-Member, are TPA's, DDTM's and (R)RW'ing.

AFAIK last time I knew, people were NOT suppose to get SRL Member from reflection scripts...

What are you trying to discuss here? Your post didn't really make that clear. So, I'll provide my insight on some topics I think you might be trying to discuss:

Reflection scripts can be shorter than color scripts? Sure, they can be.

Reflection scripts can be easier to create than color scripts? Sure, they can be.

Reflection scripts can be more efficient than color scripts? Sure, they can be.

Are you just trying to beat a dead horse here, or is this something new? :confused:

I want people to be admitted because they have real talent, not because they can push out tons of simple reflection scripts that take almost no thought.

My view on Reflection, is easier and less likely to fail. Idc if i'm sounding lazy or anything but yeah...

In theory reflection can fail, colour can't. Reflection breaks by updates. Colours scripts -if made properly- could run forever!

Color = break by updates to wtf? They could make the color of flax a totally new color, and call it magic flax. or just make it way different colors -.-

I personally never used TPAs extensively, just learned the basics of them, but from what I understand the code for every TPA is nearly the same, and all you have to do is copy/paste the whole thing and fill in a couple numbers (which you get from ACA), amiright? If so, that makes it hardly more complicated than reflection :rolleyes:

Same thing with (D)DTMs. A DTM is made by simply opening up the tool and clicking a couple of points. A DDTM is nearly the same, you just have to convert those points into code (along with actually using the dynamic part, I guess) instead of using the DTM To Text feature. (I think there's a DDTM maker of some sort as well now?)

RRW - Again, this is simply something that is hardly harder to use than reflection. How hard is it to use ACA to grab some road colors and get the best one? The radians aren't that difficult either. Not to mention most of the time people just use VarrockRoadColor or FallyRoadColor, etc.

@Above couple posts - Color rarely has downtime, but when it does, it usually requires the scripter to do more than a reflection scripter to update it. Whether that be remake their DTMs, fix up their colors, etc. A reflection scripter rarely has to do anything either, seeing as it's usually just the hooks that must be updated, resulting in a couple of hours of downtime per week.

IMO, all color is is a time consuming method that doesn't have as much effectiveness as reflection. It DOES have its benefits, and can do some things better than reflection (All of my scripts have at least bits of color in them :)), but sticking to it alone is just stubborness, I'd say. Reflection is no doubt simpler, but is not all that much easier to make (as you see above, the majority of color is just collecting data).

Both should be used in their stronger aspects is what I say (Reflection with color backup being ideal :)).

(Forgive me if I'm wrong on some of the color things, I haven't used purely color for a while :p)

Quote:

---

Originally Posted by Method

What are you trying to discuss here? Your post didn't really make that clear. So, I'll provide my insight on some topics I think you might be trying to discuss:

Reflection scripts can be shorter than color scripts? Sure, they can be.

Reflection scripts can be easier to create than color scripts? Sure, they can be.

Reflection scripts can be more efficient than color scripts? Sure, they can be.

Are you just trying to beat a dead horse here, or is this something new? :confused:

---

No, I'm simply discussing why I feel full Reflection Apps should not be accepted. Any Reflection app, IMO, should be thoroughly looked at before being voted on. I have seen some pretty nice looking Reflection scripts, and those would of course always be acceptable. As long as they show a proper knowledge of actual SRL and Scar, not just Reflection.

Just these other Reflection scripts with really know outside thinking, just Reflection functions, should be denied.

My opinion anyways.

The situation is, however, that a huge number of voters on these applications look at the first four lines of the script, see that it includes reflection, and scroll back up to the top to click "no" without taking a look at the rest of it.

Quote:

---

Originally Posted by Method

The situation is, however, that a huge number of voters on these applications look at the first four lines of the script, see that it includes reflection, and scroll back up to the top to click "no" without taking a look at the rest of it.

---

See, I don't agree with people that do that.
I don't hate Reflection, I just hate that many people use it as a way to make easy scripts as opposed to making there scripts better.

I'm thinking about using a couple Reflection fail safes in my walking for my next script even.

Quote:

---

Originally Posted by Runescapian

I personally never used TPAs extensively, just learned the basics of them, but from what I understand the code for every TPA is nearly the same, and all you have to do is copy/paste the whole thing and fill in a couple numbers (which you get from ACA), amiright? If so, that makes it hardly more complicated than reflection :rolleyes:

Same thing with (D)DTMs. A DTM is made by simply opening up the tool and clicking a couple of points. A DDTM is nearly the same, you just have to convert those points into code (along with actually using the dynamic part, I guess) instead of using the DTM To Text feature. (I think there's a DDTM maker of some sort as well now?)

RRW - Again, this is simply something that is hardly harder to use than reflection. How hard is it to use ACA to grab some road colors and get the best one? The radians aren't that difficult either. Not to mention most of the time people just use VarrockRoadColor or FallyRoadColor, etc.

@Above couple posts - Color rarely has downtime, but when it does, it usually requires the scripter to do more than a reflection scripter to update it. Whether that be remake their DTMs, fix up their colors, etc. A reflection scripter rarely has to do anything either, seeing as it's usually just the hooks that must be updated, resulting in a couple of hours of downtime per week.

IMO, all color is is a time consuming method that doesn't have as much effectiveness as reflection. It DOES have its benefits, and can do some things better than reflection (All of my scripts have at least bits of color in them :)), but sticking to it alone is just stubborness, I'd say. Reflection is no doubt simpler, but is not all that much easier to make (as you see above, the majority of color is just collecting data).

Both should be used in their stronger aspects is what I say (Reflection with color backup being ideal :)).

(Forgive me if I'm wrong on some of the color things, I haven't used purely color for a while :p)

---

What Runescapian said.



And Method is right too about people only looking at the first four lines. Today, Joker and Cycroism both did that on all that is man's application. "No because of reflection". Not right in my opinion.

When you are not applying, I think that reflection is great, when you are trying to make a really flawless script, and then post it so others can benefit. For example, Runescapians Fletcher, or his Rimmy woodcutter. Those are great scripts, and they abviously show talent as a scripter, but that is not what is needed to get member status.

So, in all, I agree with NCDS, and would like to see more color in the apps.

Im sick of

Quote:

---

nopppe, it's reflection

---

- type of votes.

If you have done a complex enough script with reflection then it's not any worse than applying with colorbased script. I personally ignore use of reflection and try to focus on the important stuff, which is general complexity, effiency, use of arrays etc.

most ppl 'hate' reflection out of ignorance either they don't understand it or are simply spiteful. if a members application contains some reflection as an extra failsafe or to make more efficient, why vote no, if they have multiplayer, tpas, dtms, etc.???

Quote:

---

Originally Posted by Smarter Child

most ppl 'hate' reflection out of ignorance either they don't understand it or are simply spiteful. if a members application contains some reflection as an extra failsafe or to make more efficient, why vote no, if they have multiplayer, tpas, dtms, etc.???

---

Thing is I have yet to see a script that has color/reflection with the other acting as a failsafe throughout, much less an applicant's script :p

SCAR Code:

function findFishingSpot: boolean;
var
  FP: tnpc;
begin
  if (FindNPC('Fishing Spot', FP)) then
    if(TileOnMS(Fp.tile, 10))then
      result := true;
end;

can be shortened even more
Code:

function FindFishingSpot : boolean;
var
FP : TNPC;
begin
result := (FindNPC('Fishing SPot', FP) and TileOnMS(Fp.tile, 10));
end;

Use something in a way it hasn't been used before. Whether its reflection or TPAs, if a mining script and a woodcutting script are the same except for a few numbers, it isn't helping the community improve. The whole reason for these groups and promotions is to bring new talent to the top. Key word is 'new'. Be creative, seed innovation and improvement.

Quote:

---

Originally Posted by Runescapian aka Tad

Thing is I have yet to see a script that has color/reflection with the other acting as a failsafe throughout, much less an applicant's script :p

---

there is one macro ftws tanner kinda does that

Just for the record, Method's "sure, they can be" should actually be "in most cases they are". That's why they vote no so often.

I haven't read the whole thread, but in my opinion it doesn't matter what you use in your application. The script has to show you understand what you are doing. Of course the script has to be of a certain level, but that level could be achieved with reflection too, no? It doesn't have to use arrays or DTM's or bitmaps or at least 12 functions + 100 keywords, it has to get the job done, it has to do what it is designed to do.