Welcome to TRiBot Forums

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.

botsallday

Botsallday Scripter Application

Scripter rank application   12 members have voted

  1. 1. Does botsallday deserve scripter rank?

    • Yes
      1
    • No
      11

Please sign in or register to vote in this poll.

9 posts in this topic

1) Snipplets: [sOURCE] (Link to thread)
N/A



2) Tutorials: [sOURCE] (Link to thread)
Filters tutorial - (Link to thread) (The "source" or "snippets" are embedded within the tutorial post)


3) Randoms/updates submitted: [sOURCE] (Link to thread)
N/A


4) Scripts available to the public: [sOURCE] (Link to thread)
Flax picker & Spinner -



Essence Miner -



Cow Killer -



Rockcrab Killer -



5) Short biography / Coding Experience: [1-2 short paragraphs]
 I have been coding pretty much daily for the past 8 years. I had written code on and off for a few years before that, but I really only picked it up seriously when I started college. I found a job toward the end of my time in college and have been working full time as a web developer ever since. I always have projects going on outside the job and tribot has proven to be a great place for that. I have really enjoyed my time in this community so far!
 
I have experience mostly with web development, but I am no stranger to OOP. I have worked in JAVA previously (hobby projects), but writing scripts here is by far the most JAVA I have ever written. I look forward to learning more about JAVA as I continue scripting!
 

6) Reasons why you feel you deserve Scripter: [1-3 short paragraphs]
I feel that I have learned quite a lot about the tribot API and JAVA through writing my scripts and working through tutorials. I am still learning new things everyday though, and I'm sure that will continue for a very long time. I try to keep an open mind and take criticism constructively because I genuinely want to improve.

I also enjoy helping other members of the community, especially other script writers. I have had a lot of very frustrating times while trying to learn languages, or just programming concepts in general. I understand how overwhelming it can be to try and learn a new language, so I try to help as much as I can when I see new scripters asking questions. I personally would not be where I am today if I hadn't received answers to thousands of questions that I have had to ask more experienced developers over the years.
 
Overall, I have done my best to learn everything that is required to be a scripter. I have also (and will always) done my best to assist anyone in the community with anything that I can. 
 

7) What you plan to provide the community with: [1-3 short Paragraphs]
I plan to provide the community with reliable scripts and the code behind them in most cases. My goal is to write scripts that are safe rather than incredibly efficient (yay abc2). I don't think there is anything wrong with efficient gold farming bots, but personally I prefer safety. I will do my best to provide reliable, safe scripts.
 
I intend to continue helping people to the best of my ability. I honestly enjoy helping with issues, even if its a simple one. I will never degrade someone for posting a question. No matter how basic the question is, or how easily they could find the answer otherwise. I plan to provide the community with all of the knowledge I possess through answering questions and sharing information in general. 


8) Do you agree to continue to not only update, but provide more free, open sourced scripts to the community? [YES/NO]
Yes! I will maintain my scripts, and continually develop open source / free scripts.


 
Responses -
  • TacoManStan : :) That is the one thing I regret about my username haha.
  • The person who voted no but did not post : Could you please comment on why you voted no, and what I could do to improve in that area?
  • The second person who voted no with no comment - Thanks.
  • The third person who voted no with no comment - Thanks.


 
Sphinx -
 
"I would really like to see more involvement within the community. You only joined just recently on the 12th of December and your scripts are less than a month old, which in my mind that makes me think you're rushing yourself to produce quantity and not quality.
"
So the amount of time my scripts have been released in addition to how long I have been here is what you are using as a metric to judge the quality of my scripts? Two of the three (you used the minimum number of scripts) scripts used in your application are younger/newer than some of mine. SPX Cow killer was submitted DEC27, Planker was JAN 1. Your application was a day after that. So two of the bare minimum 3 scripts you submitted for your scripter rank were submitted right around 1 week before you submitted your application. Heck, the planker was like 1 day. Your scripts were barely a week old when you applied. I would like to point out that my scripts are old than yours were when you applied. As for my involvement in the community, I have provided more free open source scripts than you. I have also provided more scripts overall than you. I even wrote a filters tutorial for you to use to improve your scripts since that was one of the main pieces of feedback you got. 
 

"NOTE: Not sure if this application will be applicable because you haven't implemented ABC2."
 
^ Here is a link to the requirements. I see that it asks for full ABCL10 implementation, but nothing about ABC2.. https://tribot.org/forums/topic/6550-application-guidelines/. Also since you have only missed ABC2 by about a week, should we take your scripter rank away until you re-submit an application with full ABC2?

 
"Your API is not really an API as it focuses specifically on the script. An API is essentially a library of methods or other things that are used across all your scripts so you aren't constantly re-writing the same stuff over and over again."
 
^ Care to explain a bit more on that? My api is used across all of my scripts and is not focused on any single one. I have looked at your link and do not see what you were pointing out. What am I supposed to see from your bitbucket link? That you have an api that is structured very similarly to mine? You also use a lot of magic numbers in your scripts. That is wrong and should be done with constants.
 
I am not rushing quantity over quality, I assure you of that. I may have only been here for a month, but I have spent a lot of time in that month learning the API. The scripts I have written are more complex than the ones you used in your application by far, so this coming from you shows me a great deal about you as a person. Most of your advice seems to be incorrect and conflicts with what I have been told by more experienced scripters. Thank you for the few pieces that are helpful, though.

  • Methods being too short - I prefer smaller methods as it is easier to debug. I don't think too many small methods is a bad thing.
  • Using part of the name - This generally only excludes one letter and is not a bad thing at all. I do this because I am checking contains, not equals.
  • My if statements used to be a lot shorter, @Final Calibur suggested making them longer because it was more efficient space wise and better for readability. It should  not be harder to debug if use properly, which I believe they are since I changed what he specifically asked me to.
  • You comment on my naming convention a lot, but do not give specifics.
  • The attack level check for picaxe is not necessary as if it fails to equip the pic thats no big deal. I could add it as another feature I suppose, but yeah not necessary.
  • Checking if I failed a path is not inefficient (enough to matter) and it helps with debugging.
  • healthPercent - Good advice, thank you.
  • withdrawFood - Checking if the bank is already open seems like a good idea, thanks.
  • Using dynamic clicking on food (or any inventory item) should  not be done because it is to be used for moving objects......
  • I find the nearest cow because it will not use the nearest in most cases if there is another player. Also using filters will not necessarily prevent me from getting the nearest cow as it can be used in combination with findNearest. Also, have you ever used a filter? I failed to find the use of a single filter in your code.
  • Again with the if statements, I think this is your personal preferences and not necessarily anything to do with good coding practice.
  • Convention naming, this time it seems you commented on a single variable and nothing else. Please be more specific.

Conclusion - You say there are a lot of logic problems in my scripts. Care to mention them? I have been involved in the community. I have 241 posts in my time here, and over 300 users on my scripts. I know it took you a lot longer than me, but I have been programming for a lot longer than you. It simply didn't take me as long to learn the API. Thanks for your input.
 
EDIT: I reviewed some of your code to try and get an idea of why you are being so harsh. After reviewing it, I honestly don't understand why you responded the way you did. Especially considering that your application got accepted on the premise that you were willing to learn, and not your script quality. Here are links to the review for your convenience.

Planker - https://tribot.org/forums/topic/60090-free-spx-aio-planker-abcl10-open-source-all-plank-types-coin-amount/ (Seems rushed for scripter rank application.)
AIOCooker - https://tribot.org/forums/topic/58405-free-spx-aio-cooker-open-source-4-locations-all-items-wine-making/page-2
SPXCowKiller - https://tribot.org/forums/topic/59930-free-spx-cow-killer-open-source-bank-hides-bury-bones/ (Seems rushed for scripter rank application. I stopped reviewing it early to give you time to refactor it first.)

 


 

Well everyone, thank you for coming and voting well after the 72 hour mark. I've tried to maintain my composure throughout this process, but it simply isn't worth it anymore. It just is not. This is absolutely not a fair system for working out the scripter rank. One person comes into my thread and posts some things that are definitely in the wrong and now you want to make it out like I have attacked him. I just wanted to understand where he was coming from with all of this since nearly all of his advice is either wrong or honestly not specific enough to be helpful. Never mind the fact that 3 people voted no without any comments. Never mind the fact that sphinx was clearly accepted for the wrong reasons and is now abusing his rank. Never mind the fact that the only votes I got within the 72 hour window (posted in requirements thread as "give us up to 72 hours to review the application") were no comment no votes and maybe sphinxes vote. Other than that tacoman stan posted one time with an edit on the day of the post. This process has been absolutely painful to the point that I am considering moving on to a different scripting client. If you take a look at the situation without bias, you would likely understand my point.

Edited by botsallday
4 people like this

Share this post


Link to post
Share on other sites

Took me a moment to figure out why a majority of your source is labeled "BAD"  :idea: .

 

Anyways, I'll do my best to give you some feedback when I get the time, I just felt that needed to be said.

 

EDIT:

That is the one thing I regret about my username haha.

Which is why I remain thankful that I did not choose to be known as PitaManStan.

Edited by TacoManStan
3 people like this

Share this post


Link to post
Share on other sites

NOTE: Not sure if this application will be applicable because you haven't implemented ABC2.

 

 

 

                    Main Thoughts

7ANo6V1.png

I would really like to see more involvement within the community. You only joined just recently on the 12th of December and your scripts are less than a month old, which in my mind that makes me think you're rushing yourself to produce quantity and not quality.

 

 

 

                            Code

7ANo6V1.png

  • Main
    • API
    • Classes
    • Methods
      • You seem to break down specific tasks into quite a bit of small methods which seems like you have random methods all over, you should only do this if your method is getting too long or if you have piece of code that you're finding yourself using often.
    • String's
      • A lot of your methods where you attempt to find an item or locate an object you only use part of the actual name. This honestly isn't a very good habit and shows laziness.
    • If statements
      • You seem to shove a lot of your logic into single if statements which is pretty inefficient and will cause you a lot of issues when debugging.
    • Convention Naming
      • You should work on your convention naming, it's a good habit to get into especially if you're going to be working on projects with other people in the future.
  • FlawlessEssenceMiner
    • bestUsablePickaxe
      • Your logic here seems to be flawed because while you check for the required mining level, you don't seem to check for the required attack level.
    • getPic
      • This is one of the many places where you're not checking if you actually succeeded in your task.
    • Paths
      • There are a lot of area's where you're checking if you failed walking to a position, this is not needed and inefficient.
  • FlawlessCowKiller
  • FlawlessRockCrabKiller
    • Redundancy
      • A lot of your methods for specific tasks are drastically broken up into many small methods which makes it hard to follow and can be a pain for debugging.
        • Such has detecting players, you use at least 3 or more methods just to check how many players are in the area.
    • eatFood
      • You are shoving a lot of your logic into one if statement which makes your script inefficient and hard to debug.
    • Convention Naming
      • Your convention naming is pretty poor, you are making it look like you're getting the length of your inventory when you're actually getting the length of the bad items in your inventory.

 

 

 

                      Conclusion

7ANo6V1.png

I'm going to have to vote no, there is a lot of logic issues within your scripts as well as inefficient code. I would like to see you take your time and really make sure you're involved in the community and that you have put in a lot of effort into your scripts. You're barely a month old within the community while your scripts are less than a month old.

 

I hope that if you apply again you take our advice and improve upon that.

Edited by Sphiinx

Share this post


Link to post
Share on other sites

Without looking at your code, my vote will be no simply because of attitude.

 

After looking at your code, this is what i see:

 

It is good practice to divide a script's logic in multiple files. While you do not have it in your main script file, each and everything is jammed inside of your 'core' file. Your structure is bad (heh.), i mean, a State enum in the middle of your file? Your scripts look as if you copy pasted code from everywhere and tried to glue it together.

 

Bad programming:

 

Antiban. 

You say you want to write safe scripts, but at the moment this is all but safe. Which isn't a bad thing, since your learning and all, but it isn't worthy of Scripter imo.

Examples:

And honestly i'm going to stop there, i barely even looked at one script. And i could've said a lot more about them if we are really looking at code quality. But i think the above is reason enough to justify my vote for no.

 

Just a side note, something i didn't include in your evaluation, but for the love of god don't mix tabs and spaces.

Share this post


Link to post
Share on other sites

A definite no from me.

You might want to look into the meaning of ad hominem and tu quoque.

 

"Insults are the arguments employed by those who are in the wrong." - Jean-Jacques Rousseau

Edited by TacoManStan
1 person likes this

Share this post


Link to post
Share on other sites

Originally I was not going to vote, due to potential personal bias because we've had a decent amount of discussions in the past and I really liked your attitude in general.

 

You seem to be extremely motivated and you've released a good amount of content in your time here, and these are both good signs.

 

Code quality needs work, but you've definitely improved since you've first joined. I really like that you always seem to be looking for feedback, and always take advice to heart. I believe these are natural traits that you can't teach. You've learned a decent amount in a short time, so I can't wait to see where you'll be in a few months.

 

All of that said, I'm disappointed to see how you've reacted to @Sphiinx . I didn't think your initial response in this thread was terrible, but it came off a little too hostile. I still wasn't going to vote after I read that. However, after seeing that you posted in all of his open sourced script threads with walls of code critique, I was taken back. Not only is that the wrong place to bring up concerns with his code, but it was clear that your intention behind it was spiteful.

 

It's a no from me as well. Take a step back, calm down, and realize that you can always reapply in the future. I know you have the potential, so I hope you take this application and use it as motivation to better yourself.

Share this post


Link to post
Share on other sites

This seemingly new idea of every scripter creating their own "API" needs to stop.

The last few applications have incorporated this idea of a custom "API".

In more cases then not, nearly all of the methods created are purely out of a lack of understanding of the TRiBoT API.

 

Another popular "API" idea is to literally just wrap the TRiBoT methods with the scripters own method name(s).

In some cases taking in the same exact parameter(s), and literally just calling to the TRiBoT API. 

 

These custom "API"s have become nothing more than a utility class jammed with improper methods.

It's easy to not think about proper class structure, and just throw everything into an "API" class.

The trend of these custom API's have done nothing but hinder new programmers.

 

Warfront1

Edited by warfront1
1 person likes this

Share this post


Link to post
Share on other sites

After reading your paragraph at the end of your thread, I felt it necessary to explain to you what is going on.
 
You are a new Scripter. Your 8 years of programming experience means absolutely nothing to us; the only thing that matters is the code that you present in front of us. Whether you believe yourself to be a better programmer than Sphiinx is irrelevant, because he has proven himself worthy of the Scripter role, and you have not. You have absolutely no right to insult and attack Sphiinx for providing completely legitimate advice. You are also entirely wrong about your assessment of Sphiinx's criticism. Most of his advice was entirely valid, and your dismissal of it only exposed your ignorance.

 



 
I will now go through and explain in further detail why or why not each of Sphiinx's recommendations were accurate.
 

Your API is not really an API as it focuses specifically on the script. An API is essentially a library of methods or other things that are used across all your scripts so you aren't constantly re-writing the same stuff over and over again.

This was the first thing I noticed when looking through your application (other than that everything was labeled "BAD" of course). I entirely agree with his assessment. An API should not have anything specific to any script. While you seem to understand that as a broad concept, you certainly did not adhere to it. You can see an example in which you did this here.
 

Classes

 

I agree 100% with this. Sphiinx even pointed out that it isn't necessarily a horrible thing, but that he would recommend not placing your code in a single class.
 

Methods

  • You seem to break down specific tasks into quite a bit of small methods which seems like you have random methods all over, you should only do this if your method is getting too long or if you have piece of code that you're finding yourself using often.

 

Your response to this statement was (almost) entirely wrong. You are correct in that you should limit the length of your methods as much as possible, but the last thing you want to do is create helper methods when it isn't necessary.
 
As a general rule to follow, you should only create a helper method if you find yourself needing to encapsulate a specific series of method calls. If you cannot name your helper method something specific, you should not move that specific action into a helper method.
 
In other words, do not arbitrarily create helper methods because a method is getting too long. If a method is getting too long, take a step back and analyze what it is the method is doing, and why it is getting too long. For example, are you running specific tasks within a loop, and if so, could you turn the contents of the loop into a helper method?
 
I'll leave you with this: Helper methods should make the methods in which they are helping easier to follow, not harder.
 

String's

  • A lot of your methods where you attempt to find an item or locate an object you only use part of the actual name. This honestly isn't a very good habit and shows laziness.

 

This is admittedly not always true. There are plenty of times in which it makes more sense to search for only part of an item's name. However, I would not recommend doing so out of laziness. This becomes especially tempting in cases where you are defining a lot of constants, but you should still avoid it unless it is being done by design.
 
That said, there are cases in which using contains makes more sense than equals. Again, just make sure you are doing this by design, not out of laziness.
 

If statements

  • You seem to shove a lot of your logic into single if statements which is pretty inefficient and will cause you a lot of issues when debugging.

 

I don't know what specifically is being referred to here, but this statement is correct. Cases such as these are the cases in which you would want to create helper methods.
 

Convention Naming

  • You should work on your convention naming, it's a good habit to get into especially if you're going to be working on projects with other people in the future.

 

This is entirely true, and I suggest you take it to heart.
 

FlawlessEssenceMiner

  • bestUsablePickaxe
    • Your logic here seems to be flawed because while you check for the required mining level, you don't seem to check for the required attack level.

 

You are right here; this isn't necessary, and shouldn't be included in this method. A pickaxe can be used from within the inventory, therefore making it illogical to check the player's combat level at this point.
 

FlawlessEssenceMiner

  • getPic
    • This is one of the many places where you're not checking if you actually succeeded in your task.

 

There are four main things that are wrong with this method.

  • This method should return a boolean.
  • As Sphiinx has already pointed out, you don't check if the Banking action is actually successful.
  • There is no reason to shorten pickaxe to pic. This is bad practice because pic is ambiguous. For example, getPic could be interpreted as getPicture. It is a general rule that you should not abbreviate methods unless you have a good reason in doing so.
  • The get prefix should never be used in any scenarios other than retrieving something from code. You should instead rename the method withdrawPickaxe.

FlawlessEssenceMiner

  • Paths
    • There are a lot of area's where you're checking if you failed walking to a position, this is not needed and inefficient.

 

I don't know what code is being referred to here, but saying anything "isn't inefficient enough to matter" is entirely false. If any form of calculation can be omitted without sacrificing functionality, it should be. The only exception to this rule is if a script is still in development, which this script is not.
 

FlawlessCowKiller

 

You missed the point of this advice entirely; you are needlessly calling the method Inventory#find 3 times in a row. Not only does this leave you suseptible to bugs because the result returned by Inventory#find can change, but you are consuming resources needlessly.
 
Instead, you should cache the value returned by Inventory#find, like so:

public boolean eatFood() {RSItem[] foodArr = Inventory.find(food);if (foodArr.length > 0 && foodArr[0] != null) {if (foodArr[0].hover()) {return foodArr[0].click("Eat");}}return false;}

It would be better to use Clicking#click, however, it is important that you understand what was fundamentally wrong with your method.
 

FlawlessCowKiller

  • Finding the cow
    • Instead of finding the nearest cow, you should use a filter.

 

This isn't necessarily the case. However, using a Filter is typically a good idea. That said, NPCS#findNearest is in the TRiBot API for a reason.

 

 

FlawlessRockCrabKiller

  • Redundancy
    • A lot of your methods for specific tasks are drastically broken up into many small methods which makes it hard to follow and can be a pain for debugging.
      • Such has detecting players, you use at least 3 or more methods just to check how many players are in the area.

This is NOT personal preference. What you are doing is simply incorrect.

 

Take your detectPlayers method as an example:

public boolean detectPlayers() {	// return a bool to determine if we should hop based on the number of players	if (countPlayers() > 5) {		return true;	}			return false;}

You might be able to argue that this could be used as a helper method, but regardless if it is encapsulated in a helper method or called directly, the method should be reduced to a single line of code:

countPlayers() > 5;

Unless you plan on expanding the functionality of detectPlayers, there is no reason to encapsulate such a simple calculation into a helper method.

The naming convention of the method is also incorrect; leaving the code as countPlayers() > 5 is more more descriptive.

 

FlawlessRockCrabKiller

  • eatFood
    • You are shoving a lot of your logic into one if statement which makes your script inefficient and hard to debug.

I don't necessarily agree with Sphiinx's assessment of this method. However, I couldn't help but notice that you cached the value returned by Inventory#find, which is contrary to what you did in your Cow Killer.

 

Regardless, your habit of returning true and false directly needs to be broken.

 

FlawlessRockCrabKiller

  • Convention Naming
    • Your convention naming is pretty poor, you are making it look like you're getting the length of your inventory when you're actually getting the length of the bad items in your inventory.

You asked for more specificity, but none is needed. Naming your method inventory implies that you are retrieving the items in your inventory. Improperly naming your methods like this makes your code incredibly hard to follow.

 

You should instead rename the method something along the lines of getRelevantInventory. Make sure you then document the method to explain what "relevant" items are, so the method is meaningful later when you have forgotten what it does.

 


 

As for my own advice, well, there's plenty of that to go around once you take a step back and look at this from our perspective. The Scripter role is more about proving your worth to the community, not so much proving your worth as a programmer.

Edited by TacoManStan
3 people like this

Share this post


Link to post
Share on other sites

I think there are some good tips in this thread already on some aspects where you can improve, we encourage using the Scripting Help forum for questions this review is not meant to be a personal attack and its important that you can take good feedback and criticism in this role.

 

Please re-apply when you believe you are ready based on the comments above.

1 person likes this

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.

  • Recently Browsing   0 members

    No registered users viewing this page.