Resolved RS3 Adjustable Interface

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

  1. dlinkb

    Sep 25, 2015
    Likes Received:
    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 Dawg -> Awesome -> Regal

    Jan 31, 2016
    Likes Received:
    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

    Dec 10, 2014
    Likes Received:
    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 The better executive

    Dec 3, 2013
    Likes Received:
    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