Page 1 of 4 123 ... LastLast
Results 1 to 25 of 81

Thread: Why I Vote No: A Guide to SRL Members Applications

  1. #1
    Join Date
    Jan 2008
    Location
    Ontario, Canada
    Posts
    7,805
    Mentioned
    5 Post(s)
    Quoted
    3 Post(s)

    Default Why I Vote No: A Guide to SRL Members Applications

    First off, I have been told I am a hard-ass on members applications. I'm sorry, but 9/10 of my votes are a no, and I'd love to see that changing. This tutorial has many examples, so I hope you can learn. Also, I have attached the best tutorials I could find on each subject, please look for the links!

    Please note: I do not give anyone assurance that any code works, but all code here has been written by myself. Also, this is my PERSONAL voting style, use your discretion. Some agree others disagree, I am posting this as a learning tool.

    Well, here is a list of some of the reasons why I vote no on SRL Members applications.

    1. Attitude:
      • It is key, bad attitude, no. Good attitude, Heck yes! I have voted no purely on attitude, as have others. A good attitude is your best bet into SRL members. Someone says they don't like something, ask how you can fix it. They don't like you, ask how you can fix it. Be helpful and courteous and you will get the same in return.
      • How to become Respected at SRL
    2. Sloppy Standards
      • Standards, these are OFTEN over looked but provide key readabilities. They also can improve your code altogether and make it more efficient. This is also the main reason why I will vote NO! I am not adamant on standards, I won't vote no becuase you capitalize bold words, but sloppy standards make me look deeper, and I notice other falters. All in all, good rule of thumb, hide mistakes in pretty standards.
      • Standards List
        P.S. Anyone who I have helped teach will verify that the FIRST thing I tell them is to adopt correct standards, I refuse to read it if they are bad.

    3. Large If statements
      • These are when you see things like:
        SCAR Code:
        if I = 0 then
        else
        if I = 1 then
        else
        if I = 2 then
        else
      • These are a key reason I vote no, something this big and long can be made faster and more efficient by using a simple case I of.
        SCAR Code:
        case I of
          0: Blah;
          1: Blah;
          2: Blah;
          else
            BiggerBlah;
        end;
      • There are appropriate times for large amounts of if statements, for example:
        SCAR Code:
        procedure Calibrate(Portal : String);

        var
          I : Integer;
          AInfo : AlterInfo;
          P : TPoint;

        begin
          if not R_LoggedIn then Exit;
          Portal := LowerCase(Portal);
          AInfo := SetupPortalInfo(Portal);
          P := GetMyPos;
          if DistanceFrom(EdgeToAbyss[0]) < 2 then
            Players[CurrentPlayer].Loc := 'Banking : Glory Tele'
          else
          if ChargeGlory then
            Players[CurrentPlayer].Loc := 'Charging Glories'
          else
          if TileInBox(GetMyPos, 3089, 3488, 3098, 3499) then
            Players[CurrentPlayer].Loc := 'Banking : In Bank'
          else
          if FindMeOnPath(I, EdgeToAbyss, 10) then
            Players[CurrentPlayer].Loc := 'OnPath : EdgeToAbyss'
          else
          if InCircle(P.x, P.y, 3039, 4834, 17) then
            Players[CurrentPlayer].Loc := 'OnPath : AlterTPA'
          else
          if CheckNPCsByName('Abyssal') and InCircle(P.x, P.y, 3039, 4834, 40) then
            Players[CurrentPlayer].Loc := 'OnPath : OutPath'
          else
          if TileOnMM(AInfo.ATile) then
            Players[CurrentPlayer].Loc := 'AtAlter : ' + Portal
          else
            Players[CurrentPlayer].Loc := 'Lost';
          Writeln('Player''s location is: ' + Players[CurrentPlayer].Loc);
          Disguise('Active Player: ' + Capitalize(LowerCase(Players[CurrentPlayer].Name)) +'; Loc: ' + Players[CurrentPlayer].Loc);
        end;
        Notice how every If statement has a different type of boolean statement. This cannot be made more efficient and is the best way available.
      • Need more information on cases see this: Statements Tutorial

    4. Inefficient Code.
      • This is a large reason why I vote no. If I see code being repeated multiple times for no reason, then you need to change something.
      • Option 1: Procedures / Functions If you find yourself repeating things multiple times, make it a procedure or a function. It saves lines, and looks a lot cleaner here is an example:
        SCAR Code:
        // Bad:
        //...
            if Left then
            begin
              iTime := GetTimeRunning;
              repeat
                Player := SmartGetFieldObject(0, MyPlayer);
                Result := SmartGetFieldInt(Player, CharAnim) > 0;
                SmartFreeObject(Player);
                Wait(20);
                RCC := RCC + Integer(Result);
              until (RCC = 2) or (GetTimeRunning - iTime > 500);
              Result := IsInteractingWithMe(Index) or RCC = 2;
            end;
            else
            if IsOptionMenuOpen then
            begin
              ChooseOption('ttack');
              WWM;
              iTime := GetTimeRunning;
              repeat
                Player := SmartGetFieldObject(0, MyPlayer);
                Result := SmartGetFieldInt(Player, CharAnim) > 0;
                SmartFreeObject(Player);
                Wait(20);
                RCC := RCC + Integer(Result);
              until (RCC = 2) or (GetTimeRunning - iTime > 500);
              Result := IsInteractingWithMe(Index) or RCC = 2;
            end;
        //...
        SCAR Code:
        // Good:
        function R_InFight : Boolean;

        var
          Player, RCC, iTime : Integer;

        begin
          iTime := GetTimeRunning;
          repeat
            Player := SmartGetFieldObject(0, MyPlayer);
            Result := SmartGetFieldInt(Player, CharAnim) > 0;
            SmartFreeObject(Player);
            Wait(20);
            RCC := RCC + Integer(Result);
          until (RCC = 2) or (GetTimeRunning - iTime > 500);
        end;

        //...
            if Left then
              Result := IsInteractingWithMe(Index) or R_InFight
            else
            if IsOptionMenuOpen then
            begin
              ChooseOption('ttack');
              WWM;
              Result := IsInteractingWithMe(Index) or R_InFight;
            end;
        //...
      • Option 2: Loops! Create a loop statement and use it to cycle through. Example:
        SCAR Code:
        // Bad:
          MakeCompass(IntToStr(180));
          WaitRR(200, 300);
          P := Point(Points[1].x + Random(2) - (2), Points[1].y - Random(3));
          if not TileOnMS(P, 20) then
          begin
            WalkToTile(P, 1, 0);
            R_Flag;
          end;
          P := TileToMS(P, 20);
          MMouse(P.x, P.y, 5, 5);
          WaitRR(80, 100);
          if IsUpText('limb') then
            MyMouse(['limb']);
          WaitWhileTele(2);
          WaitRR(400, 600);
          MakeCompass(IntToStr(360));
          WaitRR(200, 300);
          P := Point(Points[1].x + Random(2) - (4), Points[1].y - Random(3));
          if not TileOnMS(P, 20) then
          begin
            WalkToTile(P, 1, 0);
            R_Flag;
          end;
          P := TileToMS(P, 20);
          MMouse(P.x, P.y, 5, 5);
          WaitRR(80, 100);
          if IsUpText('limb') then
            MyMouse(['limb']);
          WaitWhileTele(2);
          WaitRR(400, 600);
        SCAR Code:
        // Good:
          for I := 1 to 2 do
          begin
            MakeCompass(IntToStr(180 * I));
            WaitRR(200, 300);
            P := Point(Points[1].x + Random(2) - (2 * (I - 1)), Points[1].y - Random(3));
            if not TileOnMS(P, 20) then
            begin
              WalkToTile(P, 1, 0);
              R_Flag;
            end;
            P := TileToMS(P, 20);
            MMouse(P.x, P.y, 5, 5);
            WaitRR(80, 100);
            if IsUpText('limb') then
              MyMouse(['limb']);
            WaitWhileTele(2);
            WaitRR(400, 600);
          end;
        Notice the good and bad sections. The good has a loop and it is half the size, it uses some math and makes it much more efficient. Saves compiling times as well.
      • Option 3: Combine Procedures! Instead of having 4 procedures to declare 4 DDTMs why not use one procedure to declare any of them?
        SCAR Code:
        // Bad:
        procedure BronzeBarD;

        var
          BColor: integer;
          SubPoints: array[0..3] of TDTMPointDef;
          MainPoint : TDTMPointDef;
          BarTDTM: TDTM;

        begin
          MainPoint.x:=68;
          MainPoint.y:=224;

          //...

          BarTDTM.MainPoint := MainPoint;
          BarTDTM.SubPoints := SubPoints;
          BarDTM := AddDTM(BarTDTM);
        end;

        procedure IronBarD;

        var
          BColor: integer;
          SubPoints: array[0..3] of TDTMPointDef;
          MainPoint : TDTMPointDef;
          BarTDTM: TDTM;

        begin
          MainPoint.x:=68;
          MainPoint.y:=224;

          //...

          BarTDTM.MainPoint := MainPoint;
          BarTDTM.SubPoints := SubPoints;
          BarDTM := AddDTM(BarTDTM);
        end;

        procedure SteelBarD;

        var
          BColor: integer;
          SubPoints: array[0..3] of TDTMPointDef;
          MainPoint : TDTMPointDef;
          BarTDTM: TDTM;

        begin
          MainPoint.x:=68;
          MainPoint.y:=224;

          //...

          BarTDTM.MainPoint := MainPoint;
          BarTDTM.SubPoints := SubPoints;
          BarDTM := AddDTM(BarTDTM);
        end;
        SCAR Code:
        // Good:
        procedure BarD(Bar: string); //I could use just a DTM with a tol of 442, but this is more accurate

        var
          BColor: integer;
          SubPoints: array[0..3] of TDTMPointDef;
          MainPoint : TDTMPointDef;
          BarTDTM: TDTM;

        begin
          case Lowercase(bar) of
            'bronze': BColor := 1451311;
            'iron': BColor := 3223861;
            'steel': BColor := 4802895;
            'mith': BColor := 4008489;
            'addy': BColor := 2831658;
            'rune': BColor := 4274988;
            else
              begin
                Writeln('Bar Color was invalid choice.');
                exit;
              end;
          end;

          MainPoint.x:=68;
          MainPoint.y:=224;

          SubPoints[0].x:=82;
          SubPoints[0].y:=223;

          //...

          BarTDTM.MainPoint := MainPoint;
          BarTDTM.SubPoints := SubPoints;
          BarDTM := AddDTM(BarTDTM);
        end;

    5. Advanced Code:
      • This is not a huge deal to me, but I do look for certain things:
      • 1: TPAs: These are a highly recommended point. They are the current style of object finding and must be used correctly. Although Custom TPAs are not absolutely necessary, I look at them as a necessity, personally, here is an example, more advanced than necessary (Its my object finder):
        SCAR Code:
        function NFindObj(Colors : TIntegerArray; UpTexts : TStringArray; w, h, minCount, Tol : Integer) : Boolean;

        var
          Pts : T2DPointArray;
          P : TPoint;
          CTS, I, Hi : Integer;
         
        begin
          CTS := GetColorToleranceSpeed;
          try
            ColorToleranceSpeed(2);
            SetArrayLength(Pts, 2);
            for I := 0 to High(Colors) do
            begin
              FindColorsSpiralTolerance(MSCX, MSCY, Pts[0], Colors[I], MSx1, MSy1, MSx2, MSy2, Tol);
              Pts[1] := CombineTPA(Pts[0], Pts[1]);
            end;
            if (Length(Pts[1]) = 0) then
            begin
              SRL_Warn('NFindObj', 'Could not find any colors.', -1);
              Exit;
            end;

            Pts := SplitTPAEx(Pts[1], w, h);
            SortATPAFrom(Pts, Point(MSCX, MSCY));
           
            Hi := High(Pts);
            for I := 0 to Hi do
            begin
              if Length(Pts[I]) < MinCount then Continue;
              P := MiddleTPA(Pts[I]);
              MMouse(P.x - 3, P.y - 3, 7, 7);
              WaitRR(80, 120);
              if IsUpTextMultiCustom(UpTexts) then
              begin
                Result := MyMouse(UpTexts);
                Exit;
              end;
            end;
            Result := False;
          finally
            ColorToleranceSpeed(CTS);
          end;
        end;
        TPA's For Dummys!
      • 2. DTMs/DDTMs: These are crucial becuase they are the basis of item finding and IMO one of the best map walking procedures, except reflection. An example of these:
        SCAR Code:
        procedure BarD(Bar: string);

        var
          BColor: integer;
          SubPoints: array[0..3] of TDTMPointDef;
          MainPoint : TDTMPointDef;
          BarTDTM: TDTM;

        begin
          case Lowercase(bar) of
            'bronze': BColor := 1451311;
            'iron': BColor := 3223861;
            'steel': BColor := 4802895;
            'mith': BColor := 4008489;
            'addy': BColor := 2831658;
            'rune': BColor := 4274988;
          end;
          if BColor = 0 then
          begin
            Writeln('Bar Color was invalid choice.');
            exit;
          end;


          MainPoint.x:=68;
          MainPoint.y:=224;
          MainPoint.areasize:=1
          MainPoint.areashape:=0;
          MainPoint.color:=BColor;
          MainPoint.tolerance:=5;

          SubPoints[0].x:=82;
          SubPoints[0].y:=223;
          SubPoints[0].areasize:=0;
          SubPoints[0].areashape:=0;
          SubPoints[0].color:=65536;
          SubPoints[0].tolerance:=0;

          SubPoints[1].x:=70;
          SubPoints[1].y:=236;
          SubPoints[1].areasize:=0;
          SubPoints[1].areashape:=0;
          SubPoints[1].color:=65536;
          SubPoints[1].tolerance:=0;

          SubPoints[2].x:=55;
          SubPoints[2].y:=231;
          SubPoints[2].areasize:=0;
          SubPoints[2].areashape:=0;
          SubPoints[2].color:=65536;
          SubPoints[2].tolerance:=0;

          SubPoints[3].x:=69;
          SubPoints[3].y:=215;
          SubPoints[3].areasize:=1;
          SubPoints[3].areashape:=0;
          SubPoints[3].color:=65536;
          SubPoints[3].tolerance:=0;

          BarTDTM.MainPoint := MainPoint;
          BarTDTM.SubPoints := SubPoints;
          BarDTM := AddDTM(BarTDTM);
        end;
        DDTM Tutorial
      • 3. Banking: Its not necessarily advanced, but it shows your script is better. I won't go into detail on this. Its too specific.

    6. The Simple Stuff, you don't think is important, but I notice and will vote no for:
      • Memory Leaks: You make a memory leak, I forget how to click yes. Simple. When you declare a DTM or a Bitmap or Call a SmartGetFieldObject you MUST free it! Here is a list of the freeing procedures:
        SCAR Code:
        procedure FreeDTM(DTM : Integer);
        procedure FreeBitmap(Bitmap : Integer);
        procedure SmartFreeObject(Object : Integer);
        Without freeing, you can crash a script, or just eat the hell out of a computers resources while also causing a lot of lag.
      • Correct Multiplayer: This should be added, it shows you know how to use logic. Its not too hard, just create a loop outside your main-loop where you switch players. Now, if you do it wrong, its worse than not at all, so be careful. Adding MultiPlayer
      • AntiBan: This is crucial, its missing? NO! Antiban ranges from random coords in ALL clicking (Within Reason) and Random Waits (Within Reason) do full out AntiBan procedures. In some of my scripts, I have no antiban procedures, it is ALL in the script itself. This can be better or worse, you pick. I will not vote yes for people who use others, regardless of credit. Adding AntiBan and AntiRandom Tutorial!
      • AntiRandoms: Insta-No if missing. These can be done using either reflection, SRL, or both. Here is a good procedure:
        SCAR Code:
        function FindRandoms : Boolean;

        begin
          Result := R_FindRandoms;
          if not Result then
            Result := FindNormalRandoms;
          if not Result then
            Result := ClickContinue(True, True);
        end;
        I will not vote a yes for people who do not create their own. Adding AntiBan and AntiRandom Tutorial!
      • Crediting: Another instant no. If you do not credit people correctly, then its a no. Also, if more than 60% of your script is someone else's its also a no. Here is an example of crediting:
        SCAR Code:
        {*******************************************************************************
        function CheckQuest(Quest: string): Boolean;
        By: lordsaturn
        Description: Will return true if the quest 'Quest' is completed, and perform the
        action declared in 'Action'.
        *******************************************************************************}


        function CheckQuest(Quest: string; Action: fnct_ActionOptions): Boolean;
        var
          arS: TStringArray;
        //...
      • Arrays, Dynamic and Static: I always look for good use of them. Dynamic arrays aren't always useful. But static arrays should ALWAYS be used when you have multiple variables, an example:
        SCAR Code:
        // Bad:
        var
          I, II, III, IIII, IIIII, IIIIII : Integer;
         
        begin
          I := 1;
          II := 2;
          III := 4;
          IIII := 3;
          IIIII := 5;
          IIIIII := 6;
         
          Writeln(IntToStr(I) + ', ' + IntToStr(II) + ', ' + IntToStr(III) + ', ' + IntToStr(IIII)
                              + ', ' + IntToStr(IIIII) + ', ' + IntToStr(IIIIII));
        end;
        SCAR Code:
        //Good:
        var
          Ints : TIntegerArray;
          S : String;
          I : Integer;

        begin
          Ints := [1, 2, 4, 3, 5, 6];
         
          for I := 0 to 5 do
            S := S + IntToStr(Ints[I]) + ', '

          Writeln(S);
        end;
        This is a poor example, as they take up similar lines, but should the array have been larger, the space saved and the length of space taken would be much greater. Also, less variables and you can use things like for loops better.
    7. Reflection:
      • Well, I love it. I will not vote no if you have it, though, unless you can really blow my socks off, I will not vote favorably to it.
      • If you have apply with a 100 line script of reflection, I will vote no since its not advanced, you use reflection well, I will vote you a yes.


    Finally, this is under-construction, if you have suggestions, please post.

    Also, I will update the formatting .

    Please let me vote more yes's
    Writing an SRL Member Application | [Updated] Pascal Scripting Statements
    My GitHub

    Progress Report:
    13:46 <@BenLand100> <SourceCode> @BenLand100: what you have just said shows you 
                        have serious physchological problems
    13:46 <@BenLand100> HE GETS IT!
    13:46 <@BenLand100> HE FINALLY GETS IT!!!!1

  2. #2
    Join Date
    Jun 2007
    Location
    south park
    Posts
    1,160
    Mentioned
    0 Post(s)
    Quoted
    62 Post(s)

    Default

    wonder why u turned me down!
    http://www.youtube.com/user/YoHoJoSRL
    Good scripting guides on youtube
    Formerly known as (djcheater)

  3. #3
    Join Date
    Jan 2008
    Location
    Ontario, Canada
    Posts
    7,805
    Mentioned
    5 Post(s)
    Quoted
    3 Post(s)

    Default

    What can I say, I'm probably too critical, but I don't like when people aren't doing their best!
    Writing an SRL Member Application | [Updated] Pascal Scripting Statements
    My GitHub

    Progress Report:
    13:46 <@BenLand100> <SourceCode> @BenLand100: what you have just said shows you 
                        have serious physchological problems
    13:46 <@BenLand100> HE GETS IT!
    13:46 <@BenLand100> HE FINALLY GETS IT!!!!1

  4. #4
    Join Date
    Sep 2008
    Location
    Not here.
    Posts
    5,422
    Mentioned
    13 Post(s)
    Quoted
    242 Post(s)

    Default

    Great tut Nava, I personally have never submitted a member application. I am going to wait until i have posted a couple of worthwhile scripts and can get all those things down before I even apply and I suggest this to anyone else who is going to apply for members. You should make a thread for your script and have people test and look at it to see if it has any problems. Then if its pretty good, apply with it. Simple as that!

  5. #5
    Join Date
    Jul 2008
    Posts
    907
    Mentioned
    0 Post(s)
    Quoted
    0 Post(s)

    Default

    Also, if less than 75% of your script is someone else's its also a no. Here is an example of crediting:
    typo?


  6. #6
    Join Date
    Jan 2008
    Location
    Ontario, Canada
    Posts
    7,805
    Mentioned
    5 Post(s)
    Quoted
    3 Post(s)

    Default

    Quote Originally Posted by SandoS View Post
    typo?
    Thanks, fixed
    Writing an SRL Member Application | [Updated] Pascal Scripting Statements
    My GitHub

    Progress Report:
    13:46 <@BenLand100> <SourceCode> @BenLand100: what you have just said shows you 
                        have serious physchological problems
    13:46 <@BenLand100> HE GETS IT!
    13:46 <@BenLand100> HE FINALLY GETS IT!!!!1

  7. #7
    Join Date
    May 2007
    Location
    Ohio
    Posts
    2,296
    Mentioned
    0 Post(s)
    Quoted
    0 Post(s)

    Default

    Heh, i believe people are going too light on the member apps... So, im so so with you..

    Cause, theres all these endless loops, functions made by other people, and stuff, and people are like, it's awsome, i vote yes! I think half of the problem is no one is really really really looking at the script...

  8. #8
    Join Date
    Sep 2007
    Location
    Pennsylvania
    Posts
    3,396
    Mentioned
    0 Post(s)
    Quoted
    0 Post(s)

    Default

    Nice tut (Yay, my tut was linked)

    Only one thing I don't agree with - Custom TPAs being a 'must'. IMO, it's really nice if the scripter has some, but if not, personally, I don't hold it against them. But it's your choice of course.

    Rep++

    EDIT: @Timer, Fakawi himself said a couple months ago that we were going too hard, and now I believe it has only gotten harder.

    EDIT2: Wow, I repped you recently, or maybe I just haven't repped anyone else...

  9. #9
    Join Date
    Mar 2007
    Posts
    3,042
    Mentioned
    1 Post(s)
    Quoted
    14 Post(s)

    Default

    This points out quite a bit of the things I look for too (and I think I vote no on a lot of applications too). Take note of these tips, Junior Members, and incorporate the techniques into your scripts.
    :-)

  10. #10
    Join Date
    Jul 2007
    Location
    Players[CurrentPlayer].Loc:='Bank'
    Posts
    875
    Mentioned
    0 Post(s)
    Quoted
    0 Post(s)

    Default

    http://www.villavu.com/forum/showthr...=35644?t=38429

    I think you need to read this.....Those are some pretty harsh standards.
    Quote Originally Posted by sirlaughsalot
    .... Obama had the devil jump out of his ass, run and stab Hillary in the back...
    ILMMTYAEAFHPY.

  11. #11
    Join Date
    Feb 2006
    Location
    New Zealand
    Posts
    1,330
    Mentioned
    0 Post(s)
    Quoted
    0 Post(s)

    Default

    I disagree slightly.

    Standards should not be such a huge deal. If someone can indent so its readable then there is NO issue. I just dont understand how you can be a master programmer, and yet not put a ; on the end of all the lines. It just seems stupid to me. I DO NOT use proper standards, yet I have never had someone complain to me about readability of my code.

    Readability is a must, but standards to the letter is a no.

    I do agree with the compactness of scripts and not having them slide all over the place.

    I dont think custom TPA's are a must. I can code an entire script that does exactly what is required without using TPA's. Yes i do use them. No they are not essential.

    To me it seems we are expecting something amazing from the people that are on the outside. We expect amazing things to get into the development team, not to let you into the members area.

  12. #12
    Join Date
    Apr 2007
    Location
    Australia
    Posts
    4,163
    Mentioned
    9 Post(s)
    Quoted
    19 Post(s)

    Default

    Quote Originally Posted by Pyro View Post
    I disagree slightly.

    Standards should not be such a huge deal. If someone can indent so its readable then there is NO issue. I just dont understand how you can be a master programmer, and yet not put a ; on the end of all the lines. It just seems stupid to me. I DO NOT use proper standards, yet I have never had someone complain to me about readability of my code.

    Readability is a must, but standards to the letter is a no.

    I do agree with the compactness of scripts and not having them slide all over the place.

    I dont think custom TPA's are a must. I can code an entire script that does exactly what is required without using TPA's. Yes i do use them. No they are not essential.

    To me it seems we are expecting something amazing from the people that are on the outside. We expect amazing things to get into the development team, not to let you into the members area.
    All of this, plus this: Functionality is more important than anything really. If a script functions as its meant to, regardless of what "advanced" techniques are/arent used then its a good script. This should be taken into consideration...

    I just don't think you should automatically vote no on people who don't use certain methods, when its quite possible they dont because they know a simpler method or have never heard of the "proper" method before.

    Fun fact: I didnt know DTMs or TPAs until long after I was SRL Members and had a master cup - proof that you dont need to know every scripting technique under the sun to be a good scripter. I didn't know cases either, the loop which actually caught Fawki's attention was a massive set of if then's inside if then's inside if then's....with something like 9 possibilities. Could of been done much easier using a case, but I obviously didn't know about it, and the logic I used to circumvent it and other things earnt me the master cup. According to this list I wouldnt have even been an SRL Member.

    So in conclusion: look for talent, not for someone who can study a list and tailor a script around it to please the SRL members

  13. #13
    Join Date
    Oct 2007
    Location
    #srl
    Posts
    6,102
    Mentioned
    39 Post(s)
    Quoted
    62 Post(s)

    Default

    I agree 100% with Pyro and The Claw.

  14. #14
    Join Date
    Sep 2007
    Location
    Michigan
    Posts
    3,862
    Mentioned
    2 Post(s)
    Quoted
    1 Post(s)

    Default

    I concur with Pyro and The Claw.

    Summary:
    1. Standards should not be as so critical. If there is a readability problem thats different. Standards can be worked on long after ur a member, I'm still kinda working on them as a Dev.

    2. Custom TPAs and DTMs were not important for getting into members before. I got in with only find colors with a well working fighter and custom functions.
    (Scripts outdated until I update for new SRL changes)
    AK Smelter & Crafter [SRL-Stats] - Fast Fighter [TUT] [SRL-Stats]
    If you PM me with a stupid question or one listed in FAQ I will NOT respond. -Narcle
    Summer = me busy, won't be around much.

  15. #15
    Join Date
    Jan 2007
    Location
    the middle of know-where
    Posts
    1,308
    Mentioned
    0 Post(s)
    Quoted
    1 Post(s)

    Default

    Quote Originally Posted by Narcle View Post
    I concur with Pyro and The Claw.

    Summary:
    1. Standards should not be as so critical. If there is a readability problem thats different. Standards can be worked on long after ur a member, I'm still kinda working on them as a Dev.

    2. Custom TPAs and DTMs were not important for getting into members before. I got in with only find colors with a well working fighter and custom functions.
    I will agree and disagree with that.
    - I agree with you concurring with Pyron and The Claw .
    - I agree a script needs good (if not great) readability.
    - There should be some standards in a script but not to the point of godlyness.

    Here is where we disagree.
    - While SRL, SCAR, and SMART advance in the community, so should the standards of education evaluation.
    - You may have gotten in with only find colors and custom functions, but that was then. - Expecting what a 'good' script needs today and what a 'good' script needed ... even 4 months ago will be different. .... I see it as trying to pass a cyborg today that only knows how to turn itself on and throw a stick. It is NOT helpful to creating a conducive and advanced membership team.


    And now we conflict and agree.
    - Nava2 consider your own membership appliance, if it is not above (not the same... but above) the level of scripting you are requiring right now it would be outrageously hypocritical of you to straightforward expect perfection in SRL membership applications.
    - I agree with Nava2 in saying that membership application should be taken seriously. If the material is available to learn from and the opportunities to learn are rejected then that is the applicant's fault alone.

    Finally, some of my own ideas.
    - Maybe a few members should 'adopt' one or two juniors whom they see to be a promising student and tutor them in their ways. - By tutoring, I mean helping in the random question or directing to a certain tutorial. - Yet this is being done today.... not on a great scale because junior members may not know what they are missing out on, and that would explain the lack of questions with their scripts...and posting of what they feel they might be teased on.
    - The standards for membership change. Rightfully so, people should be able to have a way to know what is available to learn... and what they would need to know to become a member .... this would be updated on a regular basis.

    That's what I got. Don't hate my ideas... they are just opinions and thoughts of my own.
    On vacation in NeverLand,
    Code:
    typedef int bool;
    enum { false, true };

  16. #16
    Join Date
    Mar 2007
    Posts
    3,042
    Mentioned
    1 Post(s)
    Quoted
    14 Post(s)

    Default

    I think the big deal with standards is the "first impression" that an SRL Member gets when he or she looks at an application. What the user first sees in the script will usually tell them the quality of the script. If I look at a script that has spacing all over the place and looks very untidy, I'm going to assume that the code is just as bad. This bad first impression probably puts off a lot of people from looking at the rest of the application and therefore leads to a "no" vote.

    Some of you mentioned how you think you still have bad standards also. I think all that really matters is that the code has good readability and that you stay consistent throughout the script. Weird and varied indenting, adding random begin and ends, etc. are the main problem I think people have with standards, but as long as you can stick with your style, everything's fine. There is no "law of standards", but if you want your code to be read, it's expected that other people can decipher it.

    anonymity brings up a good point about the expectation level rising as more information is brought forward (for example TPAs, which were very rarely used and seemingly super advanced when I became a member). I really think that some of these techniques should be learned and applied as a user learns more, simply because the information is widely available now. There are many tutorials on TPA usage, for example, and there are a ton of competent members on the forums and IRC to help anyone out with problems or errors they may have as a result of learning the new concept. As the technologies available increase, so should the expectation level (within reason, of course).

    The Claw mentions how he used a ton of nested if statements to get the job done back on his script. I really think innovation is something that should be looked for and recognized (in his case, using switch statements instead). Using inefficient coding methods is usually an indication that the user doesn't have much experience in the environment they are coding in, which means to me that they still have more to learn before becoming an SRL Member.

    Anyways, those are my thoughts on the above few posts. Let me know if I made a mistake or if you have any thoughts.
    :-)

  17. #17
    Join Date
    Dec 2006
    Location
    Program TEXAS home of AUTOERS
    Posts
    7,934
    Mentioned
    26 Post(s)
    Quoted
    237 Post(s)

    Default

    Good Job putting time into this..


    same im hard on appz.

  18. #18
    Join Date
    Sep 2006
    Posts
    5,219
    Mentioned
    4 Post(s)
    Quoted
    1 Post(s)

    Default

    I agree that you should keep in mind that scripting techniques change over time. If you look at the scripts of the scripters that the founding devs of SRL looked up to, the god-fathers of SCAR scripting, they really aren't that great compared to today's scripts. RGB auto coloring, TPAs, etc didn't get popular until relatively recently (also DDTM's, but I'll let that one slide because it wasn't available back then). So many scripters that learned to script before these techniques were popular didn't get used to using them. Newer scripters however, are excepted to. This may seem unfair, that higher standards are being placed on new scripters, but without this, we would all be stuck in the stone age. We shouldn't be hearing "it's better than the script I got in with back in the day, automatic yes", or any comparisons to old apps. Just think about the current 'state of the union'.

  19. #19
    Join Date
    Jan 2008
    Location
    NC, USA.
    Posts
    4,429
    Mentioned
    0 Post(s)
    Quoted
    4 Post(s)

    Default

    Quote Originally Posted by Boreas View Post
    I agree that you should keep in mind that scripting techniques change over time. If you look at the scripts of the scripters that the founding devs of SRL looked up to, the god-fathers of SCAR scripting, they really aren't that great compared to today's scripts. RGB auto coloring, TPAs, etc didn't get popular until relatively recently (also DDTM's, but I'll let that one slide because it wasn't available back then). So many scripters that learned to script before these techniques were popular didn't get used to using them. Newer scripters however, are excepted to. This may seem unfair, that higher standards are being placed on new scripters, but without this, we would all be stuck in the stone age. We shouldn't be hearing "it's better than the script I got in with back in the day, automatic yes", or any comparisons to old apps. Just think about the current 'state of the union'.
    I think that is the most valid thing writen in this entire thread. SCAR/SRL/Scripts must get better as Rs gets harder to auto at. We need new methods for things that couldnt be recognised with the old ones. There for, the bar must rise to produce faster, more accurate scripts.
    Quote Originally Posted by irc
    [00:55:29] < Guest3097> I lol at how BenLand100 has become noidea
    [01:07:40] <@BenLand100> i'm not noidea i'm
    [01:07:44] -!- BenLand100 is now known as BenLand42-
    [01:07:46] <@BenLand42-> shit
    [01:07:49] -!- BenLand42- is now known as BenLand420
    [01:07:50] <@BenLand420> YEA

  20. #20
    Join Date
    Feb 2007
    Posts
    3,616
    Mentioned
    0 Post(s)
    Quoted
    0 Post(s)

    Default

    I agree with what Boreas said.

    Back when I applied to be a member, I had only been scripting about 2 weeks. I made a power miner that pretty much just used if FindColorTolerance then MMouse if IsUpText then Mouse with some fail safes and that got me in with all yes's. It was like a 305 line script, simple, with multi player and all the obviously required stuff, but it was simple.

    If I applied with that script today, all the srl members would rip it apart and I would probably get all no's.

    I, like the claw, didn't really know TPA's or any of that fancy crap before I was made member. Even now, I understand TPA's, but I've never written a script using them before, even though I've written some good working scripts in the past.

    So I guess what I'm trying to say is that I think standards have been raised a lot for srl members over the few years I've been here. But I think that we should look for good running scripts over good looking scripts. TPA's are great and stuff, but if 1 member uses TPA's and the script works okay, and another doesn't but their script works great, who's really the better scripter?

  21. #21
    Join Date
    Jan 2008
    Location
    Ontario, Canada
    Posts
    7,805
    Mentioned
    5 Post(s)
    Quoted
    3 Post(s)

    Default

    Quote Originally Posted by richk1693 View Post
    http://www.villavu.com/forum/showthr...=35644?t=38429

    I think you need to read this.....Those are some pretty harsh standards.
    No, I disagree with the Fawk on this one. I think that the standard for an SRL member needs to increase. Its a right, and a deserved one. I'm not harsh, I'm a realist.

    Quote Originally Posted by Pyro View Post
    I disagree slightly.

    Standards should not be such a huge deal. If someone can indent so its readable then there is NO issue. I just dont understand how you can be a master programmer, and yet not put a ; on the end of all the lines. It just seems stupid to me. I DO NOT use proper standards, yet I have never had someone complain to me about readability of my code.

    Readability is a must, but standards to the letter is a no.

    I do agree with the compactness of scripts and not having them slide all over the place.

    I dont think custom TPA's are a must. I can code an entire script that does exactly what is required without using TPA's. Yes i do use them. No they are not essential.

    To me it seems we are expecting something amazing from the people that are on the outside. We expect amazing things to get into the development team, not to let you into the members area.
    Readability is key, I apologize, I didn't mean to be so... harsh on it I guess, I meant to say that it is very very very important, and it makes me wnat to help and read it. Since its not a chore to read through poor standards.

    Amazing is relative, I don't see amazing apps (usually) I see mediocre and poor. Sometimes there are good apps. Good apps are ones which follow most if not all of the guide lines I laid out and I do vote no.

    My biggest push to vote yes is attitude.

    Quote Originally Posted by The Claw View Post
    All of this, plus this: Functionality is more important than anything really. If a script functions as its meant to, regardless of what "advanced" techniques are/arent used then its a good script. This should be taken into consideration...

    I just don't think you should automatically vote no on people who don't use certain methods, when its quite possible they dont because they know a simpler method or have never heard of the "proper" method before.

    Fun fact: I didnt know DTMs or TPAs until long after I was SRL Members and had a master cup - proof that you dont need to know every scripting technique under the sun to be a good scripter. I didn't know cases either, the loop which actually caught Fawki's attention was a massive set of if then's inside if then's inside if then's....with something like 9 possibilities. Could of been done much easier using a case, but I obviously didn't know about it, and the logic I used to circumvent it and other things earnt me the master cup. According to this list I wouldnt have even been an SRL Member.

    So in conclusion: look for talent, not for someone who can study a list and tailor a script around it to please the SRL members
    I disagree, you were in at a "simpler" time. You didn't need to know the advanced techniques. Macros with the new runescape require new skills. These skills need to be part of those who develop the better scripts. And those who are willing to learn them deserve to be recognize for it.

    I agree with looking for talent, but I disagree with ignoring things for it.

    Last time I checked, you can't get good grades in university if you hand write everything and have white-out covering the page where you made mistakes.

    Quote Originally Posted by Boreas View Post
    I agree that you should keep in mind that scripting techniques change over time. If you look at the scripts of the scripters that the founding devs of SRL looked up to, the god-fathers of SCAR scripting, they really aren't that great compared to today's scripts. RGB auto coloring, TPAs, etc didn't get popular until relatively recently (also DDTM's, but I'll let that one slide because it wasn't available back then). So many scripters that learned to script before these techniques were popular didn't get used to using them. Newer scripters however, are excepted to. This may seem unfair, that higher standards are being placed on new scripters, but without this, we would all be stuck in the stone age. We shouldn't be hearing "it's better than the script I got in with back in the day, automatic yes", or any comparisons to old apps. Just think about the current 'state of the union'.
    There should be a "dynamic equilibrium" of sorts which will increase as the need increases. RuneScape is getting more and more complicated, scripting gets harder and harder, the old scripts just aren't acceptable anymore and new ones need to be developed. P.S. I agree.
    Writing an SRL Member Application | [Updated] Pascal Scripting Statements
    My GitHub

    Progress Report:
    13:46 <@BenLand100> <SourceCode> @BenLand100: what you have just said shows you 
                        have serious physchological problems
    13:46 <@BenLand100> HE GETS IT!
    13:46 <@BenLand100> HE FINALLY GETS IT!!!!1

  22. #22
    Join Date
    Feb 2007
    Posts
    3,616
    Mentioned
    0 Post(s)
    Quoted
    0 Post(s)

    Default

    Quote Originally Posted by Nava2 View Post
    No, I disagree with the Fawk on this one. I think that the standard for an SRL member needs to increase. Its a right, and a deserved one. I'm not harsh, I'm a realist.
    I think it has more to do with your ego... Self proclaimed "hard-ass"

  23. #23
    Join Date
    Jan 2008
    Location
    Ontario, Canada
    Posts
    7,805
    Mentioned
    5 Post(s)
    Quoted
    3 Post(s)

    Default

    Quote Originally Posted by JAD View Post
    I think it has more to do with your ego... Self proclaimed "hard-ass"
    No offense, taken, but no offense intended by the following, but you don't even know me? How can you make that assumption?

    Edit: It's not self-proclaimed, I have been told this by at least two people if not more, and I figure I might as well try and HELP the ones who need it. This seemed like a good idea. If you disagree feel free to navigate away.
    Writing an SRL Member Application | [Updated] Pascal Scripting Statements
    My GitHub

    Progress Report:
    13:46 <@BenLand100> <SourceCode> @BenLand100: what you have just said shows you 
                        have serious physchological problems
    13:46 <@BenLand100> HE GETS IT!
    13:46 <@BenLand100> HE FINALLY GETS IT!!!!1

  24. #24
    Join Date
    Sep 2007
    Location
    Michigan
    Posts
    3,862
    Mentioned
    2 Post(s)
    Quoted
    1 Post(s)

    Default

    Quote Originally Posted by JAD View Post
    I think it has more to do with your ego... Self proclaimed "hard-ass"
    So his opinion doesn't matter because Fawki said otherwise in a thread made how long ago? Hardly a justification to call him a "hard ass."
    (Scripts outdated until I update for new SRL changes)
    AK Smelter & Crafter [SRL-Stats] - Fast Fighter [TUT] [SRL-Stats]
    If you PM me with a stupid question or one listed in FAQ I will NOT respond. -Narcle
    Summer = me busy, won't be around much.

  25. #25
    Join Date
    Feb 2007
    Posts
    3,616
    Mentioned
    0 Post(s)
    Quoted
    0 Post(s)

    Default

    Quote Originally Posted by Nava2 View Post
    No offense, taken, but no offense intended by the following, but you don't even know me? How can you make that assumption?
    Because that's how the typical srl member seems to be right now, and from what I gathered from this post, you seem to be the same. I think it's sad that all the SRL members are up on their high horse because they have a little bit of power thinking they're mr. big shot because they can decide somebody's fate. And if they vote yes to make somebody a member, then that new member has just as much power as them, and that makes them feel less powerful.

    I shouldn't have said anything, but I just think that the average srl member's attitude is changing for the worse.

    Sorry, I'll navigate away now.

    @Narcle, he said he's a hard-ass in his post... I wasn't calling him one.

Page 1 of 4 123 ... LastLast

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. The Vote
    By OzzyStoned in forum News and General
    Replies: 21
    Last Post: 03-02-2009, 10:27 PM
  2. Vote For Us
    By BenLand100 in forum News and General
    Replies: 28
    Last Post: 12-11-2007, 03:23 PM
  3. Post link to your SRL Member Applications. [SRL MEMBERS ONLY]
    By n3ss3s in forum The Bashing Club / BBQ Pit
    Replies: 28
    Last Post: 09-25-2007, 09:11 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •