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

    • 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...