Jump to content

adamhackz scripter application

Recommended Posts

Snippets: [Source] n/a

Tutorials: [Source]




3. Open source scripts available to the public:

Clue hunter collector 








source: https://github.com/not-tivia/TRiBot/tree/master/cannonalcher

Progressive bowstringer


source: https://github.com/not-tivia/TRiBot/blob/master/aBowStringer


4. Short biography / Coding Experience: 


I've been into writing scripts for every game I've played and was never happy with the options and customization that most scripts offered for runescape botting. After learning basic Lua and writing League of Legends scripts, I realized there were no scripts that worked how I wanted them to for runescape and that developers didn't want to add every single request they received, so I took it onto myself with no concept of OOP or Java at all and just went for it.

Over the last couple years I think I've improved a lot, and enjoy learning now things and fixing my old code with the improvements that I've learned


5. Reasons why you feel you deserve Scripter: I have been an active part of the community for a long time now, and have been writing scripts for TRiBot for years when I see that there's something lacking or a script exists with not enough variety, I like to work on bringing that to life so other people have the options to use it too. 


6. What you plan to provide the community with: 

There's a couple things that I want to be able to work on as a scripter for TRiBot. I know a lot about the game and think that is one of the things that makes me stand out when it comes to writing scripts, I know what different methods look like when done by legit players, and a lot of ways that people would train or want options to have their bots blend in easier.

I want to work on scripts for iron men and main accounts primarily but I love the precedent set by Aropupu and naton of having basically unlimited options and customization, and that's something that I also want to carry on with the scripts that I provide to people



 7. Do you agree to continue to not only update, but provide more free, open sourced scripts to the community?

Yes, I think thats one of the things TRiBot needs more of.



I can't believe after all this time I didn't notice that I spelled torstol wrong 😦

I had an HP check just to make sure that looting would return false if the players HP was low enough to die from getting hit by monsters they run by, since with safespot cannoning youre usually just idling at places for a pretty long amount of time and regen your health back. Although I guess it would be a better idea to have that in its own function instead of just throwing it in with the looting

For inArea I guess I should just make it so the script won't start if the cannonarea or cannontile are null, Ill change that right now. One of the biggest things I need to work on is realizing that theres so many more things I can store as variables 😆

I've never really done anything with abstract classes before but I can see how that would have been much prettier.


edit2: I'll probably actually end up changing my clue hunter script over the next eeek even though it's not technically needed, just for practices sake, also going to be going through all the feedback and working it implementing it into my scripts as I genuienly do want to keep improving. I've been looking at the comments and have made a few small changes so far such as the mouse speed range, fixing a typo, and replacing a hardcoded value I accidentally left in.


Edited by adamhackz
Mobile edit
Link to post
Share on other sites

Hi Adam,

I am looking through your CannonAlcher script and will provide some feedback below.

  RSGroundItem[] lootlist = GroundItems.findNearest("Torstal seed", "Snapdragon seed", "Ranarr seed", "Long bone", "Curved bone");

You have a typo and would miss any "Torstol seed" drops.  This isn't really an issue that reflects upon your coding, but it is a fairly major mistake as that is the most valuable item in the list.


private boolean needsToLoot() {
        if (!lootingEnabled || Inventory.isFull() || getHpPercent() <= eatAt) {
            return false;
        //Might want to change this to loop through the lootlist and then
        // check if we can reach each one for occasions when more than one loot item is on the floor
        //Removed the reaching check so we can use this method for telegrabbing
        RSGroundItem[] lootlist = GroundItems.findNearest("Torstal seed", "Snapdragon seed", "Ranarr seed", "Long bone", "Curved bone");
        return lootlist.length > 0;

You check your hp in this method for some reason, but don't have any eating code nor any handler for what to do when we are low health (those are the only instances of getHpPercent() and eatAt in the class).  Not sure why your hitpoints are applicable in a method for checking loot on the ground.  This isn't anything necessarily wrong, but maybe you forgot to add eating in other parts of the script?


    private boolean inArea() {
        if (cannonArea == null || cannonTile == null || Player.getRSPlayer() == null || Player.getPosition() == null) {
            return false;
        return cannonArea.contains(Player.getRSPlayer().getPosition());

Just a lot of redundant code here.  I didn't check exactly how the GUI works, but I assume you are checking if the cannon area is null here because the user may not have specified something.  Rather than checking that every loop, you can check it after the GUI is finished and forget about it!  Also, since you are grabbing your Player position you may as well save it to a variable and use that when checking if the cannonArea contains it.


Next I am going to comment on the cluehuntercollector - specifically the Items:
Every one of your items contains several of the same methods.  This would have been a good opportunity to define an abstract class which forces those classes to implement the same methods - run(), inArea(), getState(), etc.  You could also add a boolean method to determine if it's already been completed (we have the item).  This can be very useful in a variety of scenarios, one that comes to mind is you can store them in a list and handle them in any order without caring about which item you are actually working with.  It would have also helped cut out a ton of extra code (and time spent writing that code).


I think that you have proven that you are willing to work and learn, and you have been a helpful member of this community for a long time.  I would have no problems welcoming you to the Scripters, however I think you have quite a bit of work ahead for a premium quality script.  It's a yes from me.


  • Like 3
Link to post
Share on other sites

A few quick observations from me; not all are necessarily "wrong" but can be considered poor programming practice or poor botting practice. Cleaning up these things would help you get to a higher script quality for public use:


From CannonAlcher:

Mouse.setSpeed(General.random(95, 280));

This is a super big range of speeds, and doing a straight random means that a user could run at 95 for 1 hour, restart the script immediately and run at 280 from then on. Such a quick and drastic change of play style would almost definitely not be good.



Personal preference but I'd like to see these handled as states themselves, rather than just a bunch of void checks/actions thrown in a row at the beginning of your loop.


private boolean needsToLoot() {

Having this separated out as a boolean method to check if you need to loot first causes a lot of duplicated code, as Fals mentioned. Basically if this returns true, you'll perform the exact same GroundItems search a second time to find a target item. Instead, have this method perform the GroundItems search once, and if the array isn't empty, return the first item instead. That way you can cache the results in your loop, if the result is not null, then pass that resulting GroundItem to your looting method. Cuts the amount of calls in half :)



As Fals mentioned, there's a ton of duplicated methods especially in these item classes; instead you should create an abstract class named something like OutfitPiece which each of these can then inherit to let them shared those common methods. Then you can also store all the pieces in an array, etc.


A lot of the methods you use such as Banking.openBank and RSItem.click return booleans, I'd like to see you use this boolean result to better manage when you calling Timing.waitCondition, to avoid waiting 5+ seconds if the click or action failed.


General.sleep(500, 1200);

Have to call out the static sleeps; it's always more ideal to perform a conditional wait with something like Timing.waitCondition and using ABC reaction times (modified) if applicable. Nullable has some good info here on the forums about the appropriate flow for Action -> Sleeping -> Reaction Time.



Overall I would say your code is definitely scripter level and I'd like to see you join us on the team. I look forward to seeing you continue to improve and learn in your programming skills :)

  • Like 1
Link to post
Share on other sites

clue hunter code review (rough notes)

  • should utilize class constructors
  • overloaded loops, logic flow unclear. A better approach would be to modularize some of the logic into groups. The parent layer state logic is too high level and needs to be broken down.


if (Banking.isBankScreenOpen()){
                        Timing.waitCondition(() -> Banking.isBankScreenOpen(), General.random(1200, 2000));

                    if (tasks.get(0).contains("cloak")) {
                        if (hasItem("Clue hunter cloak")) {
                        } else {
                            General.println("Our new task is " + tasks.get(0));
                            Cloak cloak = new Cloak();

^ no confirmation of the previous logic passing before proceeding



private State SCRIPT_STATE = getState();

^ naming convention - caramel case



                case WALK_TO_AREA:

                    if (!AREA_CLOAK.equals(Player.getPosition())) {
                        if (AREA_CLOAK.isClickable() && AREA_CLOAK.isOnScreen()) {
                            Clicking.click("Walk here", AREA_CLOAK.getPosition());
                            General.sleep(1200, 3000);
                        } else {
                            if (DaxWalker.walkTo(AREA_CLOAK)) {
                                Timing.waitCondition(() -> !Player.isMoving(), General.random(600, 1100));


^ Logic flows like this should include guard blocks instead of nesting
i.e, if (AREA_CLOAK.equals(Player.getPosition())) break

  • lots of random classes that seem to be intended to be similar, but no form of inheritance ex: GlovesAndBoots, Cloak, Trousers  class



                        } else {
                            if (DaxWalker.walkTo(AREA_TROUSERS)) {
                                Timing.waitCondition(() -> !Player.isMoving(), General.random(600, 1100));

^ can nest these to `else if`


public State getState() {
        if (hasCheckedBank) {
            if (needsSpade) {
                return State.COLLECT_SPADE;
            return State.COLLECT_OUTFIT;
        } else {
            return State.CHECK_BANK;

^ the top layer if/else is redundant. can return without an else for CHECK_BANK

Overall, the script is a bit messy but I believe it still meets the Scripter level at Tribot. Yes from me.

Edited by dax
  • Like 1
Link to post
Share on other sites

Everything I'd critique has been mentioned above. Abstracting your code is a big one as it'll help clean up your current scripts massively, especially your clue hunter script.

For example, you could have an abstract class like so:

public abstract class ClueItem {

	public abstract boolean hasItem();

	public abstract RSTile getItemTile();
	public abstract String getItemName();


public class Cloak extends ClueItem {

	private final RSTile CLOAK_TILE = new RSTile(0,0,0);

	public boolean hasItem() {
		return Inventory.contains(getItemName());

	public RSTile getItemTile() {
		return CLOAK_TILE;
	public String getItemName() {
		return "Cloak";


which you could then use for each item, stopping you duplicating code and simplifying it massively. 

I definitely think you have a lot to learn and work on, but you have the basic understanding to become a Scripter and have been in the community long enough to warrant a yes vote. Please work on what you've already got and take into account what people have said. If you do, you'll do well. :)

Yes from me.

  • Thanks 1
Link to post
Share on other sites
This topic is now closed to further replies.
  • Our picks

    • What to expect from TRiBot moving forward.
        • Thanks
        • Like
      • 10 replies
    • TRiBot 12 Release Candidate

      The TRiBot team has been hard at work creating the last major version of TRiBot before the TRiBot X release. We've noticed many problems with TRiBot 11 with a lot of users preferring TRiBot 10 over 11. We've heard you, so we took TRiBot 10, added the new features introduced with 11, introduced some other new things, and created TRiBot 12. So without further adieu, here's TRiBot 12.
        • Sad
        • Like
      • 39 replies
    • Gradle is a build tool used to accelerate developer productivity.

      We recently setup a Maven repository (TRiBot Central) to make it easier for scripters to create scripts. Check it out here: https://gitlab.com/trilez-software/tribot/tribot-central/-/packages

      Furthermore, we've released a simple Gradle project to make it easy to run TRiBot and develop scripts for it. Check it out here: https://gitlab.com/trilez-software/tribot/tribot-gradle-launcher

      The goals of TRiBot Central are to:

      Deliver updates to TRiBot faster

      Better organize TRiBot's dependencies (AKA dependancies)

      Make it easier to develop scripts for TRiBot

      Make it easier to use and run TRiBot

      Note: TRiBot won't be able to run scripts from within this project until TRiBot's next release.
        • Like
      • 13 replies
    • Hi everyone,

      I'd like to thank everyone for their patience in this transition period. Since last week, we've worked out the remaining bugs with this integration.

      Some users have still been having issues with connecting their forums account to their Auth0 account. To resolve this, we've imported all forums accounts into Auth0.

      Unfortunately, the accounts which were imported today were using an unsupported password hashing algorithm. Hence, random passwords were set during the import.

      What does this mean for me?

      If you've previously linked your forums account to your Auth0 account, you don't have to do anything. Nothing changes for you.

      If you haven't logged in via our new login yet,

      Try logging in with your forums email address and the last password you used

      If you are unable to login, please use the "Forgot password" tool on the login page:
      Follow the instructions to reset your password
        • thonking
        • Like
      • 17 replies
    • Hello everyone,

      Last week we tried to roll out Auth0 Login, but we lost that battle. Now it's time to win the war!

      Important changes

      When logging into the client, you'll now have to enter your Auth0 account credentials instead of your forums credentials

      Note: 2FA is still handled through your forums account (for the time being)

      Changes for existing users

      You'll have to link your Auth0 account to your forums account here: https://tribot.org/forums/settings/login/?service=11

      Auth0 accounts have been created for most existing users. Please use your forums email address and password to login.

      Important notes

      Make sure to verify your email address upon creating a new Auth0 account

      When we mention your Auth0 account, we mean your account used for auth.tribot.org as displayed below
      • 81 replies
  • Recently Browsing   0 members

    No registered users viewing this page.

  • Create New...