Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
UKF_HHA

[FREE] Lazy Chopper & Fetcher - More features coming soon!

Recommended Posts

Hey guys,

After a long break, I decided to make a progressive chopper as a first script to re-start off with scripting.

Got myself 1-66 woodcutting while testing it.

 

Progress

 

Spoiler

12 hours run:

6432c4dcfd.png

uWpfpNb.png

sPTJlp5.png

l8AsnpB.png

 

 

Source code: Github

Activate it over here.

Current features

  • Supports normal trees, oak & willow.
  • Automatically switches tree in Lumbridge area.
  • Power-drops all kind of logs

Progress:

  • Fletching support

Upcoming features

  • Bank support in Draynor/Falador/Varrock (most F2P area)
  • New dropping pattern (keyboard alt + clicking)
  • Better paint and antiban
  • Dynamic signatures/tracking system + hiscores
  • Mule support

A Surprise is to be announced later on.

 

Code improvements and suggestions are appreciated ❤️ 

 

Best regards

UKF

Edited by UKF_HHA
Added repo link
  • Like 1

Share this post


Link to post
Share on other sites
45 minutes ago, UKF_HHA said:

Code improvements and suggestions are appreciated

I will only cover the critical issues:

  • When getUserData is called, there is no guarantee that the required game data has been loaded. The script will show incorrect values if it's started on a newly opened client.
  • A small delay should be added in the script's main loop.
  • It makes more sense to update the variable action_state at the beginning of the loop, instead of having it on the last line.
  • Storing the result of getActionState() in the action_state variable, then using this cached value is better than calling the method 5 times in the main loop, whilst the variable remains unused.
  • tree.getDefinition() != null && tree.getDefinition().getName() != null - There is no guarantee that the second RSObjectDefinition will be non-null. This value should be cached, null checked, and only then it would be safe to use. But in this particular case, you can delete the entire line because it doesn't serve any purpose other than increasing the likelihood of the script crashing.
  • All the static sleeps must be immediately removed.

 

Thanks for your contribution.

Looking forward to seeing your progress in scripting.

 

  • Like 2

Share this post


Link to post
Share on other sites
17 hours ago, Einstein said:

I will only cover the critical issues:

  • When getUserData is called, there is no guarantee that the required game data has been loaded. The script will show incorrect values if it's started on a newly opened client.
  • A small delay should be added in the script's main loop.
  • It makes more sense to update the variable action_state at the beginning of the loop, instead of having it on the last line.
  • Storing the result of getActionState() in the action_state variable, then using this cached value is better than calling the method 5 times in the main loop, whilst the variable remains unused.
  • tree.getDefinition() != null && tree.getDefinition().getName() != null - There is no guarantee that the second RSObjectDefinition will be non-null. This value should be cached, null checked, and only then it would be safe to use. But in this particular case, you can delete the entire line because it doesn't serve any purpose other than increasing the likelihood of the script crashing.
  • All the static sleeps must be immediately removed.

 

Thanks for your contribution.

Looking forward to seeing your progress in scripting.

 

 

Updated on Github :)

Share this post


Link to post
Share on other sites

I'm quite prone to doing things like this myself, but why have an Axe enum and resort to this?

    private Axe getOptimalAxe() {
        if (Skills.SKILLS.WOODCUTTING.getActualLevel() < 6) {
            return Axe.IRON;
        } else if (Skills.SKILLS.WOODCUTTING.getActualLevel() <= 10) {
            return Axe.STEEL;
        } else if (Skills.SKILLS.WOODCUTTING.getActualLevel() <= 20) {
            return Axe.BLACK;
        } else if (Skills.SKILLS.WOODCUTTING.getActualLevel() <= 30) {
            return Axe.MITHRIL;
        } else if (Skills.SKILLS.WOODCUTTING.getActualLevel() <= 40) {
            return Axe.ADAMANT;
        } else if (Skills.SKILLS.WOODCUTTING.getActualLevel() <= 60) {
            return Axe.RUNE;
        } else {
            return Axe.DRAGON;
        }
    }

when instead you could store the value in the enum, and then just iterate it.

private Axe getOptimalAxe(){
Axe bestAxe;
for (Axe axe : Axe.values()) {
 if (Skills.getActualLevel(Skills.SKILLS.WOODCUTTING) >= axe.getLevelRequired())
	bestAxe = axe;
}
return bestAxe;
}

 

  • Like 3

Share this post


Link to post
Share on other sites
1 hour ago, UKF_HHA said:

Updated on Github :)

Yes, it seems a little bit better and you've fixed some of the points that I've posted above.

I would still recommend that you set void as the return type for most of your game-interacting methods, because the boolean value they currently return means nothing, and even if it had any meaning it is never used.

 

Also, I've seen that you have copy-pasted the snipped I've sent you which explains in detail how conditional sleeping works.

I've sent you this code because you've asked me to explain this concept. You should write the code yourself line by line, at least 3 time if you want to learn and make progress. Copy-pasting code doesn't get you anywhere.

KFYRYFv.png

 

  • Like 1

Share this post


Link to post
Share on other sites
1 minute ago, Einstein said:

Yes, it seems a little bit better and you've fixed some of the points that I've posted above.

I would still recommend that you set void as the return type for most of your game-interacting methods, because the boolean value they currently return means nothing, and even if it had any meaning it is never used.

 

Also, I've seen that you have copy-pasted the snipped I've sent you which explains in detail how conditional sleeping works.

I've sent you this code because you've asked me to explain this concept. You should write the code yourself line by line, at least 3 time if you want to learn and make progress. Copy-pasting code doesn't get you anywhere.

KFYRYFv.png

 

 

I was testing it, my bad, I am pushing an update in a bit with some features added, thanks to the explanation.

  • Like 1

Share this post


Link to post
Share on other sites
On 12/10/2018 at 7:49 PM, HeyImJamie said:

I'm quite prone to doing things like this myself, but why have an Axe enum and resort to this?

    private Axe getOptimalAxe() {
        if (Skills.SKILLS.WOODCUTTING.getActualLevel() < 6) {
            return Axe.IRON;
        } else if (Skills.SKILLS.WOODCUTTING.getActualLevel() <= 10) {
            return Axe.STEEL;
        } else if (Skills.SKILLS.WOODCUTTING.getActualLevel() <= 20) {
            return Axe.BLACK;
        } else if (Skills.SKILLS.WOODCUTTING.getActualLevel() <= 30) {
            return Axe.MITHRIL;
        } else if (Skills.SKILLS.WOODCUTTING.getActualLevel() <= 40) {
            return Axe.ADAMANT;
        } else if (Skills.SKILLS.WOODCUTTING.getActualLevel() <= 60) {
            return Axe.RUNE;
        } else {
            return Axe.DRAGON;
        }
    }

when instead you could store the value in the enum, and then just iterate it.

private Axe getOptimalAxe(){
Axe bestAxe;
for (Axe axe : Axe.values()) {
 if (Skills.getActualLevel(Skills.SKILLS.WOODCUTTING) >= axe.getLevelRequired())
	bestAxe = axe;
}
return bestAxe;
}

 

 

Thanks man, going to push it in the next update.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

  • Our picks

    • This update features:

      Fixed broken hooks from today's update


      Fix wilderness level with RuneLite (Thanks @Todd)


      Add support for Kotlin .class files in scripts (Thanks @wastedbro)


      Overhaul Inventory API (Thanks @wastedbro)


      Add List support for common methods


      Change method grouping to make more sense (by functionality)


      Refactor methods to utilize Java 8 streams instead of cumbersome loops




      Recognize chatbox minimization (Thanks @JoeDezzy1)


      Fix Screen#isInViewport when NPC chat is open (Thanks @JoeDezzy1)


      Fix login bot bugs (Thanks @erickho123)


      Fix hint arrow return values (Thanks @Encoded)


      Fix depositAllExcept functionality (Thanks @wastedbro)


      Change containing box interface bound and adjust for Y values (Thanks @erickho123)
        • Like
      • 151 replies
    • This release will:

      Fix prayers and world hopper API (Thanks @JoeDezzy1 and @erickho123)


      Improve banking API (Thanks @Encoded)


      Adds methods for returning and using Java Lists, rather than arrays


      Slightly randomizes some hardcoded behaviour


      Removes sleeps from waitConditions; the efficiency saving potential is negligible in these use-cases, therefore cleaner code is preferable


      Other back-end improvements





      Note: If you are using LG, please restart both the RS client and TRiBot.
        • Sad
        • Haha
        • Thanks
        • Like
      • 90 replies
    • This release will:

      Add new internal framework for capturing exceptions


      Fix issue with not selecting the last column in world hopper (Thanks @Todd)


      Add a message about pin usage in Banking#openBank (Thanks @Todd)


      Disable the firewall by default (Thanks @Todd)


      Fix handling of the welcome screen after login (Thanks @Encoded)


      Fix wrong amount bank withdrawal (Thanks @Encoded)


      Fix Screen#isInViewport


      Fix Game#isInViewport (Thanks @Encoded)


      Call onBreakEnd for ListenerManager Breaking Listeners (Thanks @Encoded)


      Fix Prayer#getPrayerPoints NumberFormatException (Thanks @JoeDezzy1)



      Note: If you are using LG, please restart both the RS client and TRiBot.
        • Thanks
        • Like
      • 28 replies
    • This release will:

      Fix LG for both OSBuddy and RuneLite


      Fix issue where the resizable client isn't able to be made smaller (Thanks @JoeDezzy1)


      Fix detection of the logout game tab when resizable mode and side panels are enabled (Thanks @JoeDezzy1)


      Add initial support for Sentry to allow us to identify and easily debug exceptions happening with all TRiBot users


      Add methods to determine if the bank is actually loaded, and not just the overarching interface (Thanks @wastedbro)



      Upcoming updates:

      Improved CLI support


      Full Sentry support


      Much more
        • Like
      • 64 replies
    • This release will:

      Fix NPE in Camera API (Thanks @wastedbro)


      Update deposit box interface ids (Thanks @Encoded)


      Add various bank methods (Thanks @wastedbro)


      Banking#getWithdrawXQuantity


      Banking#getDefaultWithdrawQuantity


      Banking#arePlaceholdersOn




      Fix resizeable minimap bug (Thanks @wastedbro)


      Remove Java 8 requirement


      Please note: TRiBot is not yet fully compatible with Java 10+




      Fix the break handler issues by ensuring the break handler thread never gets paused


      Fix broken settings hooks



      Upcoming updates:

      Improved CLI support


      Much more



      Note: If you are using LG, please restart both the RS client and TRiBot
        • Like
      • 68 replies
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...