1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Resolved RS3 Adjustable Interface

Discussion in 'Developer Support' started by dlinkb, Oct 10, 2016.

  1. dlinkb

    Joined:
    Sep 25, 2015
    Messages:
    1
    Likes Received:
    0
    I'm trying to get back into botting and was wondering about how scripts bots handle the different ways the interface could be setup. (I'm assuming that everyone isn't just told to use the legacy interface and that scripts bots should support different interfaces since I couldn't find any faqs or instructions saying to do so).

    Anyways, I see in the API that all intractable have a getInteractablePoint() function, which I assume returns the point on the game canvas that corresponds to the interactable.

    Given one such point on the game canvas (even if it isn't from an interactable, and I just pulled the point out of my ass), is there a way to check if it's blocked by some interface? Is the best way to do this just to iterate through all the interfaces and see if any overlap with my point?

    And are there many scenarios when I'd actually have to do something like that as a script bot maker, or are details like that almost always handled by the API? (e.g. if I call the interact method on an NPC or a tree, will it know to check if it can actually be interacted w/ and isn't behind my inventory? does the isVisible method consider whether something's behind some interface element?)

     
  2. Best Answer:
    Post #3 by SlashnHax, Nov 14, 2016
  3. awesome123man

    awesome123man Go check out new bots and give helpful feedback.

    Joined:
    Jan 31, 2016
    Messages:
    5,413
    Likes Received:
    1,662
    Well most interfaces that aren't the usual are closed by the interface handler built into runemate and enabled by default. As far as visibility, I believe stuff the bot cannot click through make isVisible false, but I may be wrong
     
  4. SlashnHax

    Joined:
    Dec 10, 2014
    Messages:
    3,198
    Likes Received:
    1,041
    Yeah, you'd be wrong in that case. Projecting the bounds for all of the "blocking interfaces" would be a very expensive thing to do, greatly increasing resource usage for every getInteractionPoint(), isVisible() and getBounds() call. Some developers may have their own approach to this issue, but at the moment it's not handled by the API.

    One such approach that I've used in the past has been to keep track of interaction failures in a row, and then forcing a camera movement when the amount of failures reaches a threshold. Another approach I use is identifying the "blocking interfaces" and taking that into account within my custom interaction method to determine whether I can interact with the target or not. I hope to refine this approach and make it efficient enough to implement it into the API :)
     
  5. Aidden

    Aidden Author of MaxiBots

    Joined:
    Dec 3, 2013
    Messages:
    6,482
    Likes Received:
    990
    You forgot to mention that it does indeed detect some blocking interfaces but only the most common ones like inventory and that (iirc). It might also be wise to note that things like walls and stuff aren't taken into consideration when determining the visibility of objects either.
     

Share This Page

Loading...