[dlinkb]

I'm trying to get back into botting and was wondering about how scripts 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 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 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?)

 

[awesome123man]

I'm trying to get back into botting and was wondering about how scripts 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 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 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?)

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

 

[slashnhax]

As far as visibility, I believe stuff the bot cannot click through make isVisible false, but I may be wrong

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

 

[aidden]

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

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.