Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
ScriptsForMains

Interfaces and equipped items

Recommended Posts

Posted (edited)
Quote

I have a couple of questions and I was wondering if you would be able to help me understand how I should go about creating a skeleton for the code/how I should code it.

...

But the things I am currently struggling on are:

1) How do you properly implement Interfaces (by using the interface explorer I can find the Parent, Child and Component but I cannot seem to get it to work properly). 

Example of my current structure:

       ... Hidden for privacy


2) How should I structure my code so that it uses a games necklace which is already equipped?

 

Any help you may have here would really be appreciated.  

**** READ THROUGH REPLIES, BETTER SCRIPTERS THAN ME HAVE RESPONDED WITH SUGGESTIONS ****

Someone asked me the above, figured I would post the answer so other people can come across it while searching...
1)  To use the interface, check if it's substantiated then call it in the following manner.  

if(Interfaces.isInterfaceSubstantiated(parentID,childID,componentID)){
    if (Interfaces.get(parentID,childID,componentID).click("Buy 50")) {
        println("Successfully bought plant pot packs");
    } else {
        println("Failed to buy plant pots... Lag?");
    }
}

The more experienced scripters told me I should dynamically allocate those interface values since they change over time.  This is from my open source "potBuyer" script... Check out the development section for a github link, it has the dependencies.  The original lanapi files have a true that needs changed to a false somewhere... If you use mine it's already updated

public void setInterfaceValues(){ //Dynamically update shop interface values
    vanessa[0].click("Trade" );
    General.println("Finding interface");
    General.sleep(3000,5000);
    RSInterface[] vanessaShop = Entities.find(InterfaceEntity::new)
            .componentNameContains("pot pack")
            .getResults();
    if(vanessaShop.length>0) {
        parentID = vanessaShop[0].getParent().getParent().getIndex();
        println("Shop ID updated: "+parentID);
        childID = vanessaShop[0].getParent().getIndex();
        println("Shop's Item Array ID updated: "+childID);
        componentID = vanessaShop[0].getIndex();
        println("Shop's Item ID updated: "+componentID);
        RSInterface closeShop = Entities.find(InterfaceEntity::new)
                .actionEquals("Close")
                .inMaster(parentID)
                .getFirstResult();
        closeID = closeShop.getIndex();
        closeChildID = closeShop.getParent().getIndex();
        println("Close shop button ID updated: "+closeID);
        interfaceValueSet=true;
    }
}

 

2) This is a simple example... It doesn't check to make sure your ring is actually a ring of dueling (it should), but this is a good starting point to make your own version.  

private boolean ringTeleport(){ //use dueling ring to teleport to clan wars
        RSItem ring = getItem(Equipment.SLOTS.RING);
        if(ring != null)
            if(ring.click("Clan Wars")) {
                return true;
            }else{return false;}
}
 
Edited by ScriptsForMains
  • Thanks 1

Share this post


Link to post
Share on other sites
15 minutes ago, ScriptsForMains said:

@HeyImJamie 

Of course, if I'm doing something incorrectly I'd love to know.  Thanks!! 

Lots of potential Null Point Exceptions as well as potential ArrayIndexOutOfBounds exceptions. Storing whether something is updated in a boolean vs just checking it's null (not null, not -1, etc.). Code cleanliness in your last block also, not necessarily "wrong" in a "will it work" sense, but not suitable for maintaining code.

Share this post


Link to post
Share on other sites

 

14 hours ago, Netami said:

Lots of potential Null Point Exceptions as well as potential ArrayIndexOutOfBounds exceptions. Storing whether something is updated in a boolean vs just checking it's null (not null, not -1, etc.). Code cleanliness in your last block also, not necessarily "wrong" in a "will it work" sense, but not suitable for maintaining code.

The code only calls "setInterfaceValues()" if vanessa.length>0...  So no IndexOutOfBounds can happen. I'm hoping people with look at the original code if they experience problems trying to implement this.  

For the null pointers, logically if it finds "pot pack" as a component, there has to be a parent/child associated with it (because of the way this shop is set up). Why do I still need to check? Is there something really bad that happens if there's a null pointer exception? I understand being super thorough about infinite loops without sleep timers (cuz it'll crash peoples' computers) but I don't understand being hyper-vigilant about null pointer checking. It seems like a really big deal though, I saw Trilez's original post about it. 
(IMPORTANT NOTE- Whenever I ask questions, I'm not trying to argue...  I'm trying to learn why we are doing things so I can become a better programmer all around. No disrespect is meant in any way.)

What do you mean by "Storing whether something is updated in a boolean vs just checking it's null (not null, not -1, etc.)."...?  The interface finder returns an RSInterface.  How would I make that into a boolean besides checking if it actually stored an RSInterface (ie !=null).  Same question with getItem().  If it's returning an RSItem, won't I have to check it with !=null?  Or do you mean something to the effect of 

boolean ringCheck = ring!=null;

(If so, why?)

 

The last code block was just to quickly show how to implement equipped items...  Looking at it again I realized it doesn't even have a return statement if no ring is equipped (therefore wouldn't even compile). I think this is what you would like to see:
 

private boolean ringTeleport(){ //use dueling ring to teleport to clan wars
        RSItem ring = getItem(Equipment.SLOTS.RING);
        if(ring != null)
                return ring.click("Clan Wars");
        return false;
}

Share this post


Link to post
Share on other sites

 

vanessa[0].click("Trade" );

I can't see the rest of your code so not sure if you're properly length checking this one or not.

 

 

if(Interfaces.isInterfaceSubstantiated(parentID,childID,componentID)){
    if (Interfaces.get(parentID,childID,componentID).click("Buy 50")) {

This can still NPE. It would be very rare, but the interface you're checking can disappear between these two statements, meaning that your .click will NPE.

 

 

        interfaceValueSet=true;

This is the line I was referencing for the boolean storage. It would be more ideal to check if the Interface id variables do not equal their default (I'd recommend initializing as -1).

 

 

private boolean ringTeleport(){ //use dueling ring to teleport to clan wars
        RSItem ring = getItem(Equipment.SLOTS.RING);
       	return (ring == null ? false : Clicking.click("Clan Wars"));
}

Few ways of doing this, the ternary operators can help compact the code and make it a bit more readable.

Share this post


Link to post
Share on other sites
8 minutes ago, Netami said:

 

private boolean ringTeleport(){ //use dueling ring to teleport to clan wars
        RSItem ring = getItem(Equipment.SLOTS.RING);
       	return (ring == null ? false : Clicking.click("Clan Wars"));
}

Few ways of doing this, the ternary operators can help compact the code and make it a bit more readable.

Why bother with ternary operators when you can just return ring != null && clicking.click, nub. ❤️

Share this post


Link to post
Share on other sites

@Netami or @HeyImJamie ...

If I call "Clicking.click(option)", does it search all clickable objects for that option? The API says you'd have to include the clickable as an option.

image.png.b1cff43305983af2b7d015b0c1138d0e.png

If it does just search all Clickables for whatever the specified option is, that's great! (and should probably be updated in the API)

Share this post


Link to post
Share on other sites
12 minutes ago, ScriptsForMains said:

@Netami or @HeyImJamie ...

If I call "Clicking.click(option)", does it search all clickable objects for that option? The API says you'd have to include the clickable as an option.

image.png.b1cff43305983af2b7d015b0c1138d0e.png

If it does just search all Clickables for whatever the specified option is, that's great! (and should probably be updated in the API)

That was my mistake, was typing too fast and forgot to add the RSItem as the second parameter to Clicking#click

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.


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