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

Shopping Snippets

Recommended Posts

// Use Interface and item ID to check if an item is in stock
public static boolean inStock(int Master, int child, int component, int... ItemID){
    //String detectactions = Interfaces.get(Master,child,component).getComponentName().trim();
    int detectactions = Interfaces.get(Master,child,component).getComponentItem();
    General.println( detectactions );
    if (ItemID[0] == detectactions && ItemID.length > 0 ){
        return true;
    }
    else return false;

}

//Minimum in shop means the shop must have atleast that much of the item before attempting to purchase
//Amount to buy should be "Buy 1", "Buy 5", "Buy 10", or "Buy 50"
public static boolean buy(int Master, int child, int component, int MinimumInShop, String... Amounttobuy) {
    String[] detectactions = Interfaces.get( Master, child, component).getActions();
    int avaliable = Interfaces.get(Master, child, component).getComponentStack();
    RSInterface buyactions = Interfaces.get(Master, child, component);
    if (Interfaces.isInterfaceValid(Master) && detectactions.length > 0 && avaliable > MinimumInShop) {
        General.sleep( 500,1200 );
    }
    return Clicking.click(Amounttobuy, buyactions);
}
Edited by adamhackz
  • Like 2
  • Sad 1
  • thonking 3

Share this post


Link to post
Share on other sites
11 hours ago, adamhackz said:
// Use Interface and item ID to check if an item is in stock
public static boolean inStock(int Master, int child, int component, int... ItemID){
    //String detectactions = Interfaces.get(Master,child,component).getComponentName().trim();
    int detectactions = Interfaces.get(Master,child,component).getComponentItem();
    General.println( detectactions );
    if (ItemID[0] == detectactions && ItemID.length > 0 ){
        return true;
    }
    else return false;

}

//Minimum in shop means the shop must have atleast that much of the item before attempting to purchase
//Amount to buy should be "Buy 1", "Buy 5", "Buy 10", or "Buy 50"
public static boolean buy(int Master, int child, int component, int MinimumInShop, String... Amounttobuy) {
    String[] detectactions = Interfaces.get( Master, child, component).getActions();
    int avaliable = Interfaces.get(Master, child, component).getComponentStack();
    RSInterface buyactions = Interfaces.get(Master, child, component);
    if (Interfaces.isInterfaceValid(Master) && detectactions.length > 0 && avaliable > MinimumInShop) {
        General.sleep( 500,1200 );
    }
    return Clicking.click(Amounttobuy, buyactions);
}

Some constructive criticism written in the JavaDoc of my updated version:

/**
 * The whole function can be simplified by reducing it to a single line of code containing 4 boolean statements.
 * In the above function you attempt to get a bunch of variables from the RSInterface, and then afterwards check if the interface is valid.
 * In my case I didn't cache any variables, however if I were to do so, before caching vars I would check the validity of the RSInterface and return false immediately if wasn't valid.
 * 
 * Note that I've not cached any variables in the function since they did not need to be cached.
 * This is a very minor memory improvement, however it will serve you well in the future if you only cached things you were going to use multiple times.
 * 
 * Since you retrieve the same interface 3 times, why not just cache it once and use it repeatedly?
 * In this example I've passed it in as a parameter so there's no need to manually cache it as a variable.
 *
 * Here I've opted to use the newly added API function Interfaces.isInterfaceSubstantiated(...).
 * It will check if the RSInterface is valid, being drawn, and not hidden, which is more thorough than simply checking the validity.
 */
public static boolean buy(RSInterface shopItem, int minStock, String ... amountToBuy) {

    return Interfaces.isInterfaceSubstantiated(shopItem) && shopItem.getActions().length > 0 && shopItem.getComponentStack() > minStock && Clicking.click(amountToBuy, shopItem);
}

Share this post


Link to post
Share on other sites
5 minutes ago, IceKontroI said:

Some constructive criticism written in the JavaDoc of my updated version:

/**
 * The whole function can be simplified by reducing it to a single line of code containing 4 boolean statements.
 * In the above function you attempt to get a bunch of variables from the RSInterface, and then afterwards check if the interface is valid.
 * In my case I didn't cache any variables, however if I were to do so, before caching vars I would check the validity of the RSInterface and return false immediately if wasn't valid.
 * 
 * Note that I've not cached any variables in the function since they did not need to be cached.
 * This is a very minor memory improvement, however it will serve you well in the future if you only cached things you were going to use multiple times.
 * 
 * Since you retrieve the same interface 3 times, why not just cache it once and use it repeatedly?
 * In this example I've passed it in as a parameter so there's no need to manually cache it as a variable.
 *
 * Here I've opted to use the newly added API function Interfaces.isInterfaceSubstantiated(...).
 * It will check if the RSInterface is valid, being drawn, and not hidden, which is more thorough than simply checking the validity.
 */
public static boolean buy(RSInterface shopItem, int minStock, String ... amountToBuy) {

    return Interfaces.isInterfaceSubstantiated(shopItem) && shopItem.getActions().length > 0 && shopItem.getComponentStack() > minStock && Clicking.click(amountToBuy, shopItem);
}

shopItems.getActions should be cached and null checked. I know its contrary to the rest of the tribot api, but string arrays need to be nullchecked not length checked.

Share this post


Link to post
Share on other sites
Just now, FALSkills said:

shopItems.getActions should be cached and null checked. I know its contrary to the rest of the tribot api, but string arrays need to be nullchecked not length checked.

Damn yeah I was trying to edit the post but the site won't let me. Updated version:

/**
 * In the above function you attempt to get a bunch of variables from the RSInterface, and then afterwards check if the interface is valid.
 * In my case I didn't cache any variables, however if I were to do so, before caching vars I would check the validity of the RSInterface and return false immediately if wasn't valid.
 *
 * Note that I've not cached any variables in the function since they did not need to be cached.
 * This is a very minor memory improvement, however it will serve you well in the future if you only cached things you were going to use multiple times.
 *
 * Since you retrieve the same interface 3 times, why not just cache it once and use it repeatedly?
 * In this example I've passed it in as a parameter so there's no need to manually cache it as a variable.
 *
 * Here I've opted to use the newly added API function Interfaces.isInterfaceSubstantiated(...).
 * It will check if the RSInterface is valid, being drawn, and not hidden, which is more thorough than simply checking the validity.
 * 
 * I do some lazy caching for String[] actions, so that if the interface isn't substantiated, it won't go on to cache the actions and will just return false.
 */
public static boolean buy(RSInterface shopItem, int minStock, String ... amountToBuy) {

    String[] actions;
    if (Interfaces.isInterfaceSubstantiated(shopItem) && (actions = shopItem.getActions()) != null && actions.length > 0 && shopItem.getComponentStack() > minStock) {
        General.sleep(500, 1200);
        return Clicking.click(amountToBuy, shopItem);
    }
    return false;
}

Variable actions for the shopItem are lazy cached, plus support has been added for sleeping before clicking.

Share this post


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

i sense verbal A B U S E

 

 

Why are you checking if the array's length is greater than 0 (checking if index 0 exists) after accessing index 0? Not only it's completely useless, but the first expression can off your script.

BA9uXCQ.png

 

Also, there is no else. If the code returns on line 2 the subsequent instructions will not be executed.

 

Ive gotten in the horrible habit of doing else return false just so I can visualize it returning false.
Trying to get over doing that.

 

5 hours ago, IceKontroI said:

Damn yeah I was trying to edit the post but the site won't let me. Updated version:

/**
 * In the above function you attempt to get a bunch of variables from the RSInterface, and then afterwards check if the interface is valid.
 * In my case I didn't cache any variables, however if I were to do so, before caching vars I would check the validity of the RSInterface and return false immediately if wasn't valid.
 *
 * Note that I've not cached any variables in the function since they did not need to be cached.
 * This is a very minor memory improvement, however it will serve you well in the future if you only cached things you were going to use multiple times.
 *
 * Since you retrieve the same interface 3 times, why not just cache it once and use it repeatedly?
 * In this example I've passed it in as a parameter so there's no need to manually cache it as a variable.
 *
 * Here I've opted to use the newly added API function Interfaces.isInterfaceSubstantiated(...).
 * It will check if the RSInterface is valid, being drawn, and not hidden, which is more thorough than simply checking the validity.
 * 
 * I do some lazy caching for String[] actions, so that if the interface isn't substantiated, it won't go on to cache the actions and will just return false.
 */
public static boolean buy(RSInterface shopItem, int minStock, String ... amountToBuy) {

    String[] actions;
    if (Interfaces.isInterfaceSubstantiated(shopItem) && (actions = shopItem.getActions()) != null && actions.length > 0 && shopItem.getComponentStack() > minStock) {
        General.sleep(500, 1200);
        return Clicking.click(amountToBuy, shopItem);
    }
    return false;
}

Variable actions for the shopItem are lazy cached, plus support has been added for sleeping before clicking.

I also appreciate this, this is incredibly helpful and to be honest I'm not suprised you were able to shorten it by so much.. I wasn't sure how I would go about just grabbing different parts of the interface without recalling it with each individual piece I wanted, Thank you.

Share this post


Link to post
Share on other sites
19 minutes ago, adamhackz said:

Ive gotten in the horrible habit of doing else return false just so I can visualize it returning false.
Trying to get over doing that.

 

I also appreciate this, this is incredibly helpful and to be honest I'm not suprised you were able to shorten it by so much.. I wasn't sure how I would go about just grabbing different parts of the interface without recalling it with each individual piece I wanted, Thank you.

Please don't tell me you still do:

private boolean plsNo;

if (plsNo == false)
		General.println("Why");

	

 

Share this post


Link to post
Share on other sites
Just now, HeyImJamie said:

Please don't tell me you still do:

private boolean plsNo;

if (plsNo == false)
		General.println("Why");

	

 

No lol

Id do something like the following even though i know it has unnecessary code lol

 

private boolean plsNo;

if (!plsNo){

General.println("badcode");
else {

return true

 

Share this post


Link to post
Share on other sites
11 hours ago, IceKontroI said:

Some constructive criticism written in the JavaDoc of my updated version:

/**
 * The whole function can be simplified by reducing it to a single line of code containing 4 boolean statements.
 * In the above function you attempt to get a bunch of variables from the RSInterface, and then afterwards check if the interface is valid.
 * In my case I didn't cache any variables, however if I were to do so, before caching vars I would check the validity of the RSInterface and return false immediately if wasn't valid.
 * 
 * Note that I've not cached any variables in the function since they did not need to be cached.
 * This is a very minor memory improvement, however it will serve you well in the future if you only cached things you were going to use multiple times.
 * 
 * Since you retrieve the same interface 3 times, why not just cache it once and use it repeatedly?
 * In this example I've passed it in as a parameter so there's no need to manually cache it as a variable.
 *
 * Here I've opted to use the newly added API function Interfaces.isInterfaceSubstantiated(...).
 * It will check if the RSInterface is valid, being drawn, and not hidden, which is more thorough than simply checking the validity.
 */
public static boolean buy(RSInterface shopItem, int minStock, String ... amountToBuy) {

    return Interfaces.isInterfaceSubstantiated(shopItem) && shopItem.getActions().length > 0 && shopItem.getComponentStack() > minStock && Clicking.click(amountToBuy, shopItem);
}

Another thing to mention, just because you can one line it doesnt mean you should. Because you one lined it, it would often create a double check on if the shop item is avaliable in the script logic..

if(canBuyItem()) // checks if its avaliable

  buy(); <-- checks again (pointless)

else

openShop();

People should cache booleans whenever possible. Not just to avoid null pointer exceptions and array index out of bounds exceptions, but to maximize effiency and lower cpu

Share this post


Link to post
Share on other sites
15 hours ago, erickho123 said:

Another thing to mention, just because you can one line it doesnt mean you should. Because you one lined it, it would often create a double check on if the shop item is avaliable in the script logic..

if(canBuyItem()) // checks if its avaliable

  buy(); <-- checks again (pointless)

else

openShop();

People should cache booleans whenever possible. Not just to avoid null pointer exceptions and array index out of bounds exceptions, but to maximize effiency and lower cpu

If your validation function is expensive and you call it multiple times unnecessarily, then this is true and you should improve your script structure.

But who makes their buy() function also validate when there is already a function dedicated to validation? That's just bad practice.

 

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

    • [CONTEST ANNOUNCEMENT] 2019 Botter's Choice Awards
      2019 Botter’s Choice Awards

      To celebrate the launch of our TRiBot Official RuneScape Bot Blog,

      we’re doing a giveaway! 

      The TRiBot Official RuneScape Bot Blog: 

      Teaching you how to do more advanced botting, faster.
      Contest Details

      Prize: 3 winners will be selected to win 25 TRiBot credits.

      How to enter:

      Respond to this forum post by November 12th tagging the thread for: 

      Your favorite script

      Provide a brief explanation (1-2 sentences) why you think that script should be put in the top 5. 

      Who can enter?

      Botter’s who are not currently scripters. Sorry scripters, the people are going to vote. Your contest is here.

      The top 5 in each category will be showcased on our TRiBot Official RuneScape Bot Blog in a “People’s Choice” section and promoted across the TRiBot website. 

      -- Credits will be awarded based on thoughtfulness and humor -- 

      Bonus points

      Use a meme in your explanation. Because we all love memes.

      *no purchase necessary. Winners will be announced on Friday, November 15, 2019 at 4:00 p.m. on our News and Announcements forum. 

      -- Vote Below -- 
        • Like
      • 28 replies
    • [READ TO THE END FOR A TEASER]

      I've noticed some new TRiBotters have had some troubles finding out sources of how to do certain things, such as using advanced scripts and often get lost in the forums.

      We are still getting posts asking where to start, what to do, recommended scripts, etc. 

      As many of you know, I am new to the team, and had troubles myself learning how to bot, let alone script. 

      So, what our team decided to do was make it easier to learn how to bot, how to script, and just become an overall better botter and scripter faster. 

      As some of you might have seen, I've posted 3 new blogs, you can check it out by clicking on the following picture or here.


      These first 3 blogs are the first of many blogs that will be TRiBot official. They are encouraged to be challenged, improved upon and act as A Best Practices Guide for Botters.

      What information would you like to see in the blogs?

      👇 [TEASER] 👇

      .

      .

      .

      We are going to be hosting a  CONTEST  this  OCTOBER.

      Its scary to think how soon you'll find out.👻

      Stay tuned.


      - RileyZ
      • 8 replies
    • Today marks a big day for TRiBot! To make it easier for users to use TRiBot, we've created installers available for every platform! These installers are all bundled with the latest version of OpenJDK 1.8 (Java 😎, which is LG compatible.

      Using TRiBot is now easy. Simply download the installer for your platform, install TRiBot, and run it. The TRiBot Loader will correctly identify the bundled JDK so there's no need to change the Java selection.

      Windows

      EXE installer: TRiBot-windows-x64-4.0.3.exe


      MSI installer: TRiBot-windows-x64-4.0.3.msi


      Portable version: TRiBot-windows-x64-4.0.3.zip


      Mac OS

      Installer: TRiBot-macos-4.0.3.dmg


      Portable version: TRiBot-macos-4.0.3.tgz


      Unix/Linux

      Installer: TRiBot-unix-4.0.3.sh


      RPM installer (CentOS/Fedora): TRiBot-linux-4.0.3.rpm


      DEB installer (Debian): TRiBot-linux-4.0.3.deb


      Portable version: TRiBot-unix-4.0.3.tar.gz


      Platform Independent

      JAR file: tribot-loader-4.0.3.jar


      Note that this jar file does not include the bundled JDK.



      Windows and Mac OS users may notice a warning message stating that the installer/application is un-recognized or un-trusted. Please ignore this message and proceed with running the installer/application. We need to acquire a code signing certificate so that we can sign the installers letting the operating system know that these files can be trusted. It will take a week or more to acquire one, so please hold tight.

      Other notable changes to the TRiBot Loader:

      Support getting the version from OpenJDK distributions


      Add check for bundled JDK


      Copy OpenJDK tools.jar to the bundled JDK if not present


      Set the current java as the first available list entry


      Ignore Java versions which are symbolic links


      Make the bundled JDK the preferred Java version


      Update icon images


      Reduce the number of HTTP calls
        • Thanks
        • Like
      • 24 replies
    • TRiBot is looking to improve a lot of its customer relationship management, customer on boarding process, customer experience, design elements, community engagement and pretty much everything else you can imagine when it comes to marketing.

      Our goal: To ensure that the marketing done TRULY reflects the experience and does not shine an inaccurate light on what TRiBot is lacking in.

      So I ask, what do you love about TRiBot and what do you hate about TRiBot? What does O S Bot, Rune M8, PowR Bot and Dre amBot do better? (yes I purposely didn't spell it right 😂).

      Love, 

      RileyZ
        • Like
      • 18 replies
    • Hello TRiBot,

      Today we have a significant release that has been in the works for the last month addressing several key issues, features and bugs in the backlog.

      With these changes, we are also including a new TRiBot Loader which will allow you to select any version that is released. This adds the flexibility of allowing you to revert to a previous version should an issue arise, run development only builds, view an accurate change log between versions etc. we are very proud to offer this feature and think it will add a lot more functionality down the road as we continue to release new versions.

      These changes include 80+ commits by our development team, a list of them is summarized below and also available for your viewing pleasure in the new TRiBot Loader.

      In addition, we have taken additional steps to improve as a development team by adding continuous integration and deployment into our workflow to assist in delivering timely releases such as bug fixes as well as new features on a weekly basis depending on our development cycle.
        • Thanks
        • Like
      • 39 replies
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...