Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Buy OSRS Gold

Sell OSRS Gold
Laniax

Entity Selector by laniax

Recommended Posts

This is my take on tribot's entity selection.

The core of tribot was written years ago, but time has not stood still and many things written back then could be achieved much simpler in today's java.
Hence why i thought it would be nice to create a minimal wrapper around some of the API methods, add some generics and lambda goodness and make it available for anyone to use.

The entity selector will allow you to retrieve NPCs, inventory items, ground items, bank items, objects, players and interfaces all with the same mindset and a few lines of code. It wraps around tribot's filters (Except interfaces, since there are no tribot filters for interfaces, i made those myself) and the added performance overhead is minimal.

Here's an example of what it looks like

RSArea cowArea = new RSArea(...);

// Find the closest attackable NPC to the player's position, inside the cow area.
RSNPC cow = Entities.find(NpcEntity::new)
        .actionsEquals("Attack")
        .inArea(cowArea)
        .sortByDistance()
        .getFirstResult();

if (cow != null) {
    // We found a attackable npc!
}

 

The code, javadocs and examples are all available on github.
https://github.com/Laniax/Entity-Selector

 

Let me know what you guys think!

Edited by laniax
  • Like 7
  • Thanks 1
  • thonking 1

Share this post


Link to post
Share on other sites
5 minutes ago, Worthy said:

All of the _____Entities reuse many of the same methods like idEquals, idNotEquals, actionEquals, etc.

You should refactor more with some abstract classes and interfaces.

They aren't reused. Every method add a specific filter to the list depending on the entity. There is not much to abstract away.

Share this post


Link to post
Share on other sites
1 minute ago, laniax said:

They aren't reused. Every method add a specific filter to the list depending on the entity. There is not much to abstract away.

I don't mean they are reused. I mean you have so much duplicate code.

An abstract class would refactor this.

 

Your methods idEquals, idNotEquals, actionContains, actionNotContains, areaEquals, etc, are copy and pasted across multiple classes 4-5 times. This can all be refactored with a sort of general entity abstract class, which your specific entity classes implement.

Share this post


Link to post
Share on other sites
2 minutes ago, Worthy said:

I don't mean they are reused. I mean you have so much duplicate code.

An abstract class would refactor this.

 

Your methods idEquals, idNotEquals, actionContains, actionNotContains, areaEquals, etc, are copy and pasted across multiple classes 4-5 times. This can all be refactored with a sort of general entity abstract class, which your specific entity classes implement.

I don't mean to sound like a dick, but i don't think you're right.

Sure many of the Entity classes share the same function names, but they all have a different method body.

Example; 

ItemEntity#idEquals
filters.add(Filters.Items.idEquals(id));

NpcEntity#idEquals
filters.add(Filters.NPCs.idEquals(id));

 

I don't think there is a way to abstract that away, since the Tribot Filters.xxxx classes do not implement a common interface. But please let me know if it is somehow possible.

Share this post


Link to post
Share on other sites
3 minutes ago, laniax said:

I don't mean to sound like a dick, but i don't think you're right.

Sure many of the Entity classes share the same function names, but they all have a different method body.

Example; 

ItemEntity#idEquals
filters.add(Filters.Items.idEquals(id));

NpcEntity#idEquals
filters.add(Filters.NPCs.idEquals(id));

 

I don't think there is a way to abstract that away, since the Tribot Filters.xxxx classes do not implement a common interface. But please let me know if it is somehow possible.

Ah, I see what you mean. I suppose you could create some sort of common interface but then implementing it you would have to use the instanceof keyword. 

 

I may end up using this anyway :).

Share this post


Link to post
Share on other sites
1 hour ago, some0ne said:

Why would i use this over NPCS.find(new Filter etc... ?
less iterations over one rsnpc object?

Iteration count will be the same.

The library makes it easier to use multiple filters, and it does the array to single entity checks for you. And generally gives you a lot more overview due to the clean oneliners, as well as the lambda support for custom filters.


That and it also includes filters for interfaces, which are not provided by the tribot api. Banking checks are simplified as well since it has built in item loading delay and thus can be called directly after Banking#openBank.

It's up to anyone if they like the syntax and ease of use.

Share this post


Link to post
Share on other sites

Added #componentNameContains and #componentNameEquals for Interfaces, which allow for easy shop interactions!

 

Example:

RSInterface shopInterface = Entities.find(InterfaceEntity::new)
                                    .componentNameContains("Tinderbox")
                                    .getFirstResult();

    if (shopInterface != null) {

        if (Clicking.click("Buy 1", shopInterface)) {
            // ...

(Note that i am using #componentNameContains because the component names usually contain HTML code as well.)

Share this post


Link to post
Share on other sites

Very eloquent code, I'm extremely impressed. Currently using this in my first TriBot script, been professionally coding for years however.

I was on the path in creating something like this on my own as I was getting a feel for the TriBot Api and noticed how annoying it was getting rsobjects and npc objects in the way I wanted. Admins definitely need to add this to the official API because I wouldn't have even known it existed without a user linking me this. 

Share this post


Link to post
Share on other sites

Wow this is insane, just found this.

Quick nooby question, in the efficient scripting post by trilez, he said that finding something by ID is the most efficient method of doing so (4th efficient being by name). 

I see that you wrote "added performance overhead is minimal" but just wanted confirmation that finding an object by ID has near identical processing speed as finding said object via .nameContains("name).getFirstResult();

Thanks

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

    • Over the past few months, I’ve been working diligently on a new project - TRiBot X. Everything has been written from the ground up, with all of the best practices of software engineering. Every aspect of TRiBot has been re-imagined to support three main goals: flexibility, useability, and reliability.
        • Like
      • 30 replies
    • Come give us feedback on the next version of TRiBot!
        • Thanks
        • Like
      • 74 replies
    • TRiBot is looking to improve a lot of its customer relationship management, customer on boarding process, customer experience, design elements, community engagement and pretty much everything else you can imagine when it comes to marketing.

      Our goal: To ensure that the marketing done TRULY reflects the experience and does not shine an inaccurate light on what TRiBot is lacking in.

      So I ask, what do you love about TRiBot and what do you hate about TRiBot? What does O S Bot, Rune M8, PowR Bot and Dre amBot do better? (yes I purposely didn't spell it right 😂).

      Love, 

      RileyZ
        • Like
      • 23 replies
    • Over the last three weeks, I've been working on upgrading our server infrastructure. It's finally ready and is now live!

      Why?

      Increased reliability - less server errors


      Increased availability - less downtime


      Increased security - keeping us and you secure


      Increased capacity - ability to serve you better


      Increased speed - less waiting for things to load


      Faster development - server and service updates will come faster


      What are the changes?

      Move from a single AWS EC2 instance to AWS ECS (Elastic Container Service)


      Distributed computing


      Load balancing


      Git management of server files and filesystem


      Redis caching


      How?

      AWS ECS (with 10 EC2 instances)


      AWS ElastiCache (Redis)


      AWS Load Balancing


      AWS EFS (Elastic file system)


      Please bare with us as I continue to tune the server for maximum performance. Slow loading speeds may occur temporarily. I thank everyone for their patience.

      Please post on this thread if you experience any issues other than slow loading times.
        • Like
      • 51 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
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...