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

Clicking RSObject behind another RSObject

Recommended Posts

Posted (edited)

My script clicks a target, an RSObject, to attempt to mine it. Problem is sometimes another object gets in the way and then the script gets stuck clicking the object obstructing the view. I'm using the isClickable() and isOnScreen() method, both which returns true even if the obstruction is blocking my target. Is there a way to make sure i can have my camera move to see the target reliably or any other solution? 

Edited by Plee

Share this post


Link to post
Share on other sites
Posted (edited)

I check via uptext to ensure that it is the right one. I think with those methods, if u input a string, then it will ensure it clicks it via a right click if it has to.

 

Here's one of my "universal" clicking methods if you want something as reference. Not for your purpose I think what I said is fine, this is just for reference.

/**
     * A safe way to ensure that you click an object.
     *
     * When normally clicking, other {@code Positionables} may obstruct your path, making you click on them instead. If
     * such case occurs, it would simply do a right click and click the uptext option.
     *
     * @param desiredUptext The option that you want to select
     * @return true if successful click, false otherwise
     */
    private static boolean safeClick(String desiredUptext)
    {
        // fail safe for spam right click on option
        if (ChooseOption.isOpen())
        {
            ChooseOption.select("Cancel");
            System.out.println("safeClick: Option right click was open, cancelling options...");
            return false;
        }

        // Before clicking, ensure nothing is in the way
        if (!Game.isUptext(desiredUptext))
        {
            Mouse.click(3);

            if (Timing.waitChooseOption(desiredUptext, 500))
            {
                ChooseOption.select(desiredUptext); // cant return this for w.e reason always false?
                return true;
            }
            else
            {
                ChooseOption.select("Cancel");
                return false;
            }
        }
        else
        {
            Mouse.click(1);
            return true;
        }
    }

 

	/**
     * With supplied parameters, ensures that the entity will be clicked.
     *
     * Does all the null checking, camera movement, zoom out to ensure the above goal is met. If returns false, you
     * need to make the account walk to object and recall.
     *
     * @param clickableEntity   An entity that is clickable and has a position
     * @param uptext            String value representing the uptext when mouse hovers the npc
     * @param animation         Desired animation when interacting with object. -1 if no animation to occur.
     * @return                  True if click was successful, false otherwise.
     **/
    private static <T extends Clickable07 & Positionable> boolean clickEntity(T clickableEntity, String uptext, int animation)
    {
        if (!clickableEntity.isClickable() && !attemptAimCamera(clickableEntity))
        {
            System.out.println("clickEntity: Unable to click entity. It is too far away; resolve from caller.");
            return false;
        }

        clickableEntity.hover();
        Timing.waitUptext(uptext, General.random(650, 800));

        BooleanSupplier boolSupp = animation == -1 ? GBooleanSuppliers.waitToStopMoving() : GBooleanSuppliers.waitForAnimation(animation);

        // Split into two if statements for readability
        if (clickableEntity.getPosition().distanceTo(Player.getPosition()) <= 1)
        {
            if (!safeClick(uptext)  ||
                !Timing.waitCondition(GBooleanSuppliers.waitForAnimation(animation), General.random(1800, 1950)))
            {
                System.out.println("clickEntity: Failed to click entity (1)");
                return false;
            }
        }
        else if (!(safeClick(uptext)                                                                     &&
                   Timing.waitCondition(GBooleanSuppliers.waitToStartMoving(), General.random(625, 800)) &&
                   Timing.waitCondition(boolSupp, General.random(5200, 5400))))
        {
            System.out.println("clickEntity: Failed to click entity (2)");
            return false;
        }

        return true;
    }

    /**
     * WastedBro's implementation (with slight tweaks) that aims the camera at an entity.
     *
     * Attempts to do so 2-5 times. This is random to avoid patterns each attempt is different than the last.
     *
     * @param clickableEntity Any Type that implements the Clickable and Positionable interfaces (RSObject, RSNPC, etc)
     * @return Whether or not the target is in camera view
     */
    private static <T extends Clickable07 & Positionable> boolean attemptAimCamera(T clickableEntity)
    {
        if(clickableEntity == null)
            return false;

        int numberOfCameraAdjusts = 0;
        int maxCameraAdjusts = General.random(2, 5);

        while(!clickableEntity.isClickable() && numberOfCameraAdjusts <= maxCameraAdjusts)
        {
            if (numberOfCameraAdjusts == 0)
            {
                Camera.turnToTile(clickableEntity);
            }
            else if (numberOfCameraAdjusts == maxCameraAdjusts)
            {
                CameraZoom.zoomOut();
            }
            else
            {
                // If we fail to find by rotation, then lower the angle (to see further)
                int angle = Camera.getCameraAngle();
                Camera.setCameraAngle(angle - General.randomSD(5, angle, 30, 11));
            }

            numberOfCameraAdjusts++;
        }

        return clickableEntity.isClickable();
    }

 

Edited by TheGengar
  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)

You can take advantage of the method RSMenuNode.correlatesTo to accurately click options that correspond to RSObjects, RSNPCs, RSPlayers, and RSInterfaces. This would require you to create your own clicking method though. If you want to stick with tribots, use the full option of the target. Ex. "Trade playerName" instead of "Trade". This won't work for things with similar naming so if you're mining I'm pretty sure they're all called "Rocks" so it may not work.

Edit: Looks like there's a clicking method that accepts a Predicate<RSMenuNode> so you wouldn't need to create your own clicking method to use RSMenuNode.correlatesTo

Edited by Naton
  • Like 1

Share this post


Link to post
Share on other sites
10 hours ago, Plee said:

isOnScreen()

Do not use this method to check if you can click something, as it only tells you if the object's tile is on screen, which is not very helpful.

 

Your best bet would be doing what @Naton said and passing more arguments to the clicking method.

Here is an example where we want to try to chop down an oak without missclicking (in this example oak is a RSObject which implements Clickable) :

oak.click();

^ This will hover over the object's model and will click there, regardless if there is something blocking the view, which can result in the script clicking the wrong object.

 

oak.click("Chop-down");

^ This will hover over the model and will successfully select the "Chop-down" option. It's better than the first method call, but it can still click other trees (which also have the same option available).

 

oak.click("Chop-down Oak");

^ This guarantees the best accuracy, and the only way it's going to miss its mark is if there's another oak blocking the view to your target oak. But that shouldn't be a problem if your script is supposed to chop down oaks. :D

 

  • Like 1

Share this post


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

Do not use this method to check if you can click something, as it only tells you if the object's tile is on screen, which is not very helpful.

 

Your best bet would be doing what @Naton said and passing more arguments to the clicking method.

Here is an example where we want to try to chop down an oak without missclicking (in this example oak is a RSObject which implements Clickable) :

oak.click();

^ This will hover over the object's model and will click there, regardless if there is something blocking the view, which can result in the script clicking the wrong object.

 

oak.click("Chop-down");

^ This will hover over the model and will successfully select the "Chop-down" option. It's better than the first method call, but it can still click other trees (which also have the same option available).

 

oak.click("Chop-down Oak");

^ This guarantees the best accuracy, and the only way it's going to miss its mark is if there's another oak blocking the view to your target oak. But that shouldn't be a problem if your script is supposed to chop down oaks. :D

 

Thank you, I was using ore.click("Mine"); but i utilized your third suggestion and it fixed the problem. Thanks for the help

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)
      • 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.
      • 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.
      • 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
      • 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
      • 68 replies
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...