Jump to content

[Tutorial] The Tribot Script SDK for users of the old API


Nullable

Recommended Posts

This tutorial is designed for those familiar with the old API, the one we've been using for 8 years and is still used in most of the scripts. It's going to highlight some of the biggest differences in the way you script with the new SDK.

 

The new SDK is currently in preview. Here are the Javadocs: https://runeautomation.com/docs/sdk/kdocs/

 

Automatic Event Handlers

In the old API, the client will forcibly take control of the client in these events:

  • Breaking
  • Pin screen input
  • Login
  • Random events

With the new SDK, some of these things are configured before the script starts. By default, the new SDK does not automatically take control for random events, login, or pin screen input. All of these are intended to be handled by the script if possible. This cuts down on the unnecessary multi-threading and gives more control to the scripter.

To change the config, simply add this optional method into your main script class:

@Override
public void configure(ScriptConfig config) {
  // modify the "config" object here
}

The pin screen will automatically be handled when using the  Bank.openBank()  method.

 

The Query API

You're probably used to having classes like  Objects  and  Npcs  and whatnot for finding the corresponding entities in the game. Many of you probably use a unified query API like Laniax's Entity Finder.

In the new SDK, we chose to implement a unified query API that tries to be as convenient and concise as possible. We believe it's so usable that we entirely removed most of the other ways of finding entities.

Simply type:

Query.

 And watch as your IDE suggests to you everything you could need. 

For a full example:

var attackingCow = Query.npcs()
    .nameEquals("Cow")
    .isInteractingWithMe()
    .findFirst();

The query builder has tons of convenient filters and methods for all sorts of things.

 

Static Setters for Message Listening

You'll notice that in the new SDK, there isn't much you can override or implement for your main script class, such as "MessageListening07". We believed that this was clunky and opinionated for no reason. It actually went against the nature of our static API.

Now we can add listeners like:

MessageListening.addServerMessageListener(message -> {
    Log.log("Got a new server message:");
    Log.log(message);
});

 

Walking

Ahh, walking..... once Tribot's great strength turned into Tribot's weakness. The old API's walking has certainly outlived its glory days. While we don't have a full replacement (yet), we have something close:

  •  GlobalWalking  - Essentially the "new" webwalker. Is currently backed by Daxwalker.
  •  LocalWalking  - Provides tools for walking within the loaded region or via premade paths. Also backed by Daxwalker and its Reachable class.

While nothing prevents you from using Daxwalker directly, using these classes will ensure you always get our updates and provide a clean interface that is compliant with any future features we add.

 

No More Null!

That's right. No more nulls. All Tribot SDK methods use Java's Optional type or return reasonable defaults. We annotated them with Jetbrain's "NotNull" annotation so that your IntelliJ IDE will point out that your null checks are unneeded :)

If for whatever reason we do have a method that returns null, we will also annotate it properly. If you're using IntelliJ, it will warn you about a missed null check.

 

No More Arrays!

Arrays... remember those? From your intro to CS class? Maybe from your programming coworkers who are over 40? Right, you know. Arrays are cumbersome. They are treated as special primitive types, which is weirdly against OOP principles, the things the Java founders were so fond of.... they are cumbersome to use, don't integrate into modern libraries, and are a pain to manipulate.

That's why the new SDK uses Java's Lists instead. They integrate better into the Stream API and have all sorts of fancy methods on them. Much nicer.

 

No More BLOAT!

Let's face it. OSRS has changed since 2013 and every time it seems the Tribot API has added something without much consideration in a class that sort of fits. Well, we're changing that. We reevaluated every single method and asked 3 questions:

  • Is this method even necessary or is there a better way?
  • Does this method describe itself well enough?
  • Does this method belong in the right class?

Any method we felt did not meet "yes" criteria on any of these questions was either removed, moved, or reworked. This lead to things such as the "MyPlayer" class, the removal of the "Clicking" class, the renaming of all the types to get rid of the "RS" prefix, and many more. The intent of this improved structure and naming is to help script code read more naturally as well as make navigating the API easier.

 

Removal of "Types" of types

Confusing headline, but hear me out. In the old API, you just "RSItem" and "RSTile", but within those objects were "type" classification. For example, an RSItem might be an "inventory type" and an RSTile may be a "World" or "Local" type.

Not in the new SDK.

In the new SDK, we separate them as different classes as the OOP gods intended. Now we have "WorldTile", "LocalTile", "InventoryItem", and "EquipmentItem".

Some methods will return the specific types. For example, the Inventory class will deal in "InventoryItem"s. And some classes will simply use the more generic "Item" class. It depends on the usage. The specific classes have specific methods.

For example, EquipmentItem#getSlot().

 

Tons. Of. New. Shit

Seriously, just bunches:

And.... a new BankTask, which is used like:

var bankTask = BankTask.builder()
    .addEquipmentItem(EquipmentReq.slot(Equipment.Slot.WEAPON).item(1329, Amount.of(1))) // mith scim
    .addEquipmentItem(EquipmentReq.slot(Equipment.Slot.AMMO).item(888, Amount.fill(5))) // mith arrows
    .addEquipmentItem(EquipmentReq.slot(Equipment.Slot.HEAD).none()) // no helm
    .addInvItem(440, Amount.range(1,5)) // iron ore
    .addInvItem(377, Amount.of(1)) // raw lob
    .addInvItem(2361, Amount.of(10)) // addy bar
    .addInvItem(379, Amount.fill(1)) // lob
    .build();

if (!bankTask.isSatisfied()) {
    bankTask.execute();
}

More coming soon!

Link to comment
Share on other sites

  • 1 month later...
  • 2 months later...
  • 8 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

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.

×
×
  • Create New...