Nullable 1114 Posted August 9, 2021 Share Posted August 9, 2021 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: Tons of methods added to the Combat class (with autocasting) Tons of methods in the new MyPlayer class More utils for Waiting A new, simple Pricing API for getting an item's GE price 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! Quote Tribot Discord: https://discord.gg/g7swtb8vA6 Link to comment Share on other sites More sharing options...
NeuroGenix 28 Posted September 29, 2021 Share Posted September 29, 2021 This looks awesome! I've been away for a long time and didn't know all this had happened, great guide! Thank you! Quote Link to comment Share on other sites More sharing options...
Mochi 2 Posted December 12, 2021 Share Posted December 12, 2021 Can you post more about how we would interact with widgets? Quote Link to comment Share on other sites More sharing options...
alex_unqie 0 Posted August 13, 2022 Share Posted August 13, 2022 this looks awesome! any example scripts to learn more about this api? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.