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

Wastedbro

Introduction to the Tribot 11 Automation Client

Recommended Posts

With the release of Tribot 11.0.9 (currently beta), a new feature is added to allow for programmatic client automation. I'm going to over how to use it, with a couple of low level examples.

 

Introduction

The Tribot Automation Client is a low-level way to interact with the client at a programmatic level. This is not a GUI feature, nor can it be set up without code (yet). In short, we've enabled the client to communicate with external applications via websockets. This allows you to connect your tribot processes to your servers, whether locally on your computer, or remote. This should provide a fantastic way to add remote features to the client, such as a bot panel, automated farm, monitoring, etc. 

Even if you never use a remote server, this interface would allow you to create tribot tooling that enables workflows that go above the script. For example, a smarter breaking system, or a better script queue, etc. You can even make your own CLI for running clients!

 

Prerequisites

  • Knowledge in webserver programming (any language)
  • Basic knowledge in websocket communication (two-way)
  • JSON-RPC 2.0 Protocol (spec link)

 

Terminology

  • server is a system that accepts connections
  • client is system that attempts to connect to a server
  • connection is a two-way communication system. Both the client and server can each send messages to each other, meaning there is no difference between them other than the way they connect. In this regard, a server can have zero-to-many client connects, and a client can only have one connection to a server.

 

How does the automation client work?

When Tribot first opens up, it will look for a config file called "automation-settings.json" within the ".tribot/settings" directory. This file will not be created automatically by tribot. You must provide it. If Tribot cannot find this file, it will not open any sockets.

This file has a single field:

{
    "webServerUrl": "http://localhost:8374"
}

All you need to provide is a URL to your server, which includes the port. In this case, Tribot will attempt to open a websocket connection to a server running on the local machine using port 8374.

Once the connection is made, the Tribot websocket client will accept messages that follow JSON-RPC 2.0 specification. It will then try to locate the method you specified to call with your arguments. It will execute the method, then return the results back in JSON-RPC format.

 

Methods for the client

Format: method(param1, param2)

  • getTabs()
    • Returns a list of open tabs for the tribot process, with their IDs, username of the account running, and the name of the script running.
    • Example return message: { "id": 1, "username": "MyRSAccount", "script": "Wasted Chopper" }
  • addNewClientTab(name, world)
    • Opens a new tab in the tribot client. The tab will be named from the "name" parameter, and will start the game in the world specified by "world". Both of these parameters can be null, and a new tab will open like normal. Returns an empty response.
  • removeClientTab(tabId)
    • Removes the specified tab from the tribot client, closing the game. This will return an empty response.
  • startScript(tabId, accountName, breakProfileName, scriptName, scriptArgs)
    • Starts a script for the specified tab, using the parameters specified. Everything except the "scriptName" and "tabId" can be null. Returns an empty response.
  • stopScript(tabId)
    • Stops a script for the specified tab. Returns an empty response.
  • pauseScript(tabId)
    • Pauses a script for the specified tab. Returns an empty response.
  • unPauseScript(tabId)
    • Unpauses a script for the specified tab. Returns an empty response.
  • getStat(tabId, stat)
    • Returns the specified stat level of the account that's logged in within the specified tab. The "stat" parameter must match the Tribot STATS enum.
  • getInventoryItems(tabId)
    • Returns a list of inventory items of the account that's logged in within the specified tab. The return value will be a 2-dimensional array, with the overarching array being the list of items, and the inner arrays being the itemID and stack at indexes 0 and 1. The inner arrays will always be 2 elements.
  • getPosition(tabId)
    • Returns the position of the account that's logged in within the specified tab. The return value will be an integer array in the format of [X, Y, Plane]. It will always be 3 elements representing the tile coordinates.
  • isLoggedIn(tabId)
    • Returns true if the game is logged in for the specified tab, and false otherwise.
  • getSetting(tabId, setting)
    • Returns the value of the specified game setting for the specified tab.
  • getVarbit(tabId, varbit)
    • Returns the value of the specified game varbit for the specified tab.

 

Webserver Example (Kotlin)

In this example, a webserver will listen on 8374. Once a client connects, it will send a request for the "getTabs" method. It will then listen for messages sent back to it for that specific client and print out any it receives.

Link: https://gist.github.com/WBScripting/258783dcfef4521fb32715254562286e

 

If you run this app, open tribot 11, then open two clients (within 10 seconds), you'll see this exchange:

Tribot Process Connected...
Sending request:
{"jsonrpc":"2.0","id":"1","method":"getTabs"}
Received Response:
{"jsonrpc":"2.0","id":"1","result":[{"id":1,"username":"unimplemented"},{"id":2,"username":"unimplemented"}]}

 

Webserver Example (Java)

Coming soon...

 

Notes:

  • The webserver can be in any language. The messages are sent through plaintext via websocket, so they are not at all language-specific. You can create automation tools in NodeJS, Java, Kotlin, C#, Python, Go, etc.
  • Most of the methods will give a response with no value. The response is what signals that the method is complete. In the future, I hope to add more info the results.
  • Your webserver doesn't need to be the system that actually controls the clients. For example, you could create a webserver that simply served up the functionality via REST API, so that you can get this information via a stateless REST service. The possibilities are endless.
  • Like 5

Share this post


Link to post
Share on other sites
Posted (edited)

Definitely going to try to make something cool with this, thanks!

I mentioned this in discord but it'd be awesome to have the ability to define custom rpc methods (which could, for example, be loaded client-side like scripts when the websocket client is created). The framework this automation client provides is very powerful. Personally, I'd like to create a bot panel that people could use to monitor their clients but without custom rpc methods the bot panel wouldn't provide much extra to users.

Edited by Naton

Share this post


Link to post
Share on other sites
3 hours ago, Naton said:

Definitely going to try to make something cool with this, thanks!

I mentioned this in discord but it'd be awesome to have the ability to define custom rpc methods (which could, for example, be loaded client-side like scripts when the websocket client is created). The framework this automation client provides is very powerful. Personally, I'd like to create a bot panel that people could use to monitor their clients but without custom rpc methods the bot panel wouldn't provide much extra to users.

What kind of functionality do you need? Perhaps we can figure something out. 

One thing we can't do is allow RPC methods to actually call API methods that send input to the client, like clicks or keys. But you can use this tool to stop a script, run your own script, then rerun the previous script. This would be helpful with muling, for example.

Share this post


Link to post
Share on other sites
2 hours ago, wastedbro said:

What kind of functionality do you need? Perhaps we can figure something out. 

One thing we can't do is allow RPC methods to actually call API methods that send input to the client, like clicks or keys. But you can use this tool to stop a script, run your own script, then rerun the previous script. This would be helpful with muling, for example.

I totally understand that - input definitely shouldn't be allowed because it would likely break things (this could be left up to the implementer to just not do dumb things? like how you shouldn't do input in your onPaint method in a script or something of that nature. People would notice pretty quickly that it would mess up their scripts if they ever did try to implement something like that).

 

A few examples of things that I would be able to handle with custom rpc methods are:

Sending screenshots. I can optimize them to be very fast by taking advantage of the fact that my server would be running java as well. There's a trick you can do with BufferedImage to send an image much quicker than something like Image.IO but its really only helpful if the server is running java as well, therefore it isn't suited well for a public method. Random optimizations like these would be benefits of having custom rpc methods. The trick involves this ((DataBufferInt) image.getRaster().getDataBuffer()).getData(); and then reloading that into a BufferedImage.

Custom server notifications. I could send notifications to the server on chat messages or death for example, that could be displayed to the user. There's so many different possibilities.

Keeping track of state client side such as a bank item cache.

 

I'm not 100% on what functionality users would want yet, its hard for me to gauge everything in advance, though I am working on figuring out what features are desired. Part of the reason I want custom rpc methods so badly is that it would allow me to add any functionality in the future that is desired with really only being limited by my own motivation.

Share this post


Link to post
Share on other sites
52 minutes ago, Naton said:

I totally understand that - input definitely shouldn't be allowed because it would likely break things (this could be left up to the implementer to just not do dumb things? like how you shouldn't do input in your onPaint method in a script or something of that nature. People would notice pretty quickly that it would mess up their scripts if they ever did try to implement something like that).

 

A few examples of things that I would be able to handle with custom rpc methods are:

Sending screenshots. I can optimize them to be very fast by taking advantage of the fact that my server would be running java as well. There's a trick you can do with BufferedImage to send an image much quicker than something like Image.IO but its really only helpful if the server is running java as well, therefore it isn't suited well for a public method. Random optimizations like these would be benefits of having custom rpc methods. The trick involves this ((DataBufferInt) image.getRaster().getDataBuffer()).getData(); and then reloading that into a BufferedImage.

Custom server notifications. I could send notifications to the server on chat messages or death for example, that could be displayed to the user. There's so many different possibilities.

Keeping track of state client side such as a bank item cache.

 

I'm not 100% on what functionality users would want yet, its hard for me to gauge everything in advance, though I am working on figuring out what features are desired. Part of the reason I want custom rpc methods so badly is that it would allow me to add any functionality in the future that is desired with really only being limited by my own motivation.

I see.

That type of functionality was supposed to be enabled by the plugin system, but that's been pushed back to Tribot X. 

 

Perhaps we can add something more primitive to Tribot 11 that would still allow this functionality. However, with the new projects going on, we might not be able to allocate the resources.

  • Like 1

Share this post


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

Would you be able to add the ability to specify an account password when starting a script (so that the accounts don't have to be in the account manager)?

Yes, I think so. I should be able to make it so you can replace the "account name" string with a JSON object like:
 

account: {
  name: "MyAccountUserName"
  password: "pass"
  pin: "1234"
}

I will try to add it this weekend.

  • Like 6

Share this post


Link to post
Share on other sites
On 6/16/2020 at 5:48 PM, Wastedbro said:

Yes, I think so. I should be able to make it so you can replace the "account name" string with a JSON object like:
 

account: {
  name: "MyAccountUserName"
  password: "pass"
  pin: "1234"
}

I will try to add it this weekend.

Has this been implemented? It would be very uesful

Share this post


Link to post
Share on other sites
Posted (edited)

Is there a way to get the websocket via script for scripters to use the socket for custom messaging to the server? 

 

Answered on discord - No, we can open our own WebSocket connection though

Edited by Plee

Share this post


Link to post
Share on other sites
Posted (edited)

Hey WastedBro, I tried two commands as of 11.3 update (the one that says it fixed the automation client) and here were my results: 

var obj = {
 16     "jsonrpc": "2.0",
 17     "id": "1",
 18     "method": "getTabs"
 20 }
  • [2020-07-19 09:56:26] Received Automation Message:
  • [2020-07-19 09:56:26] {"jsonrpc":"2.0","id":"1","method":"getTabs"}

End of response, nothing else, when you give it the data "params": [], it just returns the text "false".

Additionally, I have tried another command:

 15  var obj = {
 16     "jsonrpc": "2.0",
 17     "id": "1",
 18     "method": "addNewClientTab",
 19 	"params": ["maggy", 471]
 20 }

I get the same result: Received automation message then my json object as string back to me, no client behavior exhibited.

 

Now granted, I know that this is a very new implementation to Tribot 11 and I respect the effort to design something like this, but even if its not in its complete working state, shouldn't there be something printed in the debug in regards to my command?

Edited by maggyD

Share this post


Link to post
Share on other sites

Apologies in advance if this is not the correct place to post it.  I seem to be having an issue getting this websocket working properly. I have used the following json object in "automation-settings.json" file.

 

{
    "webServerUrl": "http://localhost:8374"
}

The port doesn't seem to respond to anything. I would expect to see a tcp port opened but I see nothing.  Any advice on how to troubleshoot this would be welcomed

tested via

nmap -sT -p8374 127.0.0.1 --reason

Starting Nmap 7.80 ( https://nmap.org )
Nmap scan report for localhost (127.0.0.1)
Host is up, received localhost-response.

PORT     STATE    SERVICE REASON
8374/tcp filtered unknown no-response

.

Share this post


Link to post
Share on other sites
26 minutes ago, Romanz said:

Apologies in advance if this is not the correct place to post it.  I seem to be having an issue getting this websocket working properly. I have used the following json object in "automation-settings.json" file.

 

{
    "webServerUrl": "http://localhost:8374"
}

The port doesn't seem to respond to anything. I would expect to see a tcp port opened but I see nothing.  Any advice on how to troubleshoot this would be welcomed

tested via

.

 

The port you're pointing Tribot to is what tribot connects to. Tribot will not open the port nor have anything that will respond to requests on that port. It's kind of the opposite. You are supposed to provide the server. The client will connect to it and accept commands from your server.

The "server" in this context being simply being something that accepts a websocket connection. You can run it locally.

Edited by Wastedbro

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

    • Gradle is a build tool used to accelerate developer productivity.

      We recently setup a Maven repository (TRiBot Central) to make it easier for scripters to create scripts. Check it out here: https://gitlab.com/trilez-software/tribot/tribot-central/-/packages

      Furthermore, we've released a simple Gradle project to make it easy to run TRiBot and develop scripts for it. Check it out here: https://gitlab.com/trilez-software/tribot/tribot-gradle-launcher

      The goals of TRiBot Central are to:

      Deliver updates to TRiBot faster


      Better organize TRiBot's dependencies (AKA dependancies)


      Make it easier to develop scripts for TRiBot


      Make it easier to use and run TRiBot


      Note: TRiBot won't be able to run scripts from within this project until TRiBot's next release.
        • Like
      • 9 replies
    • Hi everyone,

      I'd like to thank everyone for their patience in this transition period. Since last week, we've worked out the remaining bugs with this integration.

      Some users have still been having issues with connecting their forums account to their Auth0 account. To resolve this, we've imported all forums accounts into Auth0.

      Unfortunately, the accounts which were imported today were using an unsupported password hashing algorithm. Hence, random passwords were set during the import.

      What does this mean for me?

      If you've previously linked your forums account to your Auth0 account, you don't have to do anything. Nothing changes for you.


      If you haven't logged in via our new login yet,

      Try logging in with your forums email address and the last password you used


      If you are unable to login, please use the "Forgot password" tool on the login page:
      Follow the instructions to reset your password
       
        • thonking
        • Like
      • 15 replies
    • Hello everyone,

      Last week we tried to roll out Auth0 Login, but we lost that battle. Now it's time to win the war!

      Important changes

      When logging into the client, you'll now have to enter your Auth0 account credentials instead of your forums credentials

      Note: 2FA is still handled through your forums account (for the time being)



      Changes for existing users

      You'll have to link your Auth0 account to your forums account here: https://tribot.org/forums/settings/login/?service=11


      Auth0 accounts have been created for most existing users. Please use your forums email address and password to login.



      Important notes

      Make sure to verify your email address upon creating a new Auth0 account


      When we mention your Auth0 account, we mean your account used for auth.tribot.org as displayed below
      • 81 replies
    • To better support the upcoming changes (TRiBot X, new repository), we're switching our login handler to Auth0. Instead of logging in with the standard form, you'll now be required to login through our Auth0 application.

      All existing accounts which have been used within approximately the past year have been imported into Auth0 using the same email and password combination which has been stored on the forums.

      What does this mean for users?

      Your account credentials are now even more securely stored


      You'll be able to login via Facebook, Google, and others in the future


      Is there anything users have to do differently now?

      Existing users: You'll have to login with the standard login, open your Account Settings, then link your Auth0 account


      New users: You'll be redirected to our Auth0 app (auth.tribot.org) where you'll be able to create an account


      Why was this change made?

      The new apps we are creating (such as the new repository) aren't able to use the forums to handle user logins


      To centralize all user accounts in one area


      To ensure that the client login doesn't go down when the forums are having problems


      To speed up our development


      Other considerations

      There's no documentation or official support for using Invision Community combined with Auth0, so there are still a few kinks we're working out


      We're in the works of creating an account management panel specifically for Auth0 accounts (ETA August)


      It's not possible to change email addresses for the time being (this will be resolved this August)


      Changing passwords is a weird process for the time being. To change your password, you'll have to use the "Don't remember your password" tool on the Auth0 login page
        • Like
      • 11 replies
    • Over the past month, we've been working hard on TRiBot's new repository - a much needed update. This change has been deemed necessary for TRiBot X, and will allow us to really speed up development of all aspects of TRiBot.

      Today we are going to share what we've been working on!


      Now you must be wondering what kind of features the new repository will have.... well, you'll have to be patient for a little while longer. We're still figuring out various technical aspects so we can't provide answers to all possible questions. We're also focusing on development rather than writing about it so that everyone can get access to our latest developments at lightning speed. I will however answer a few users' questions.

      We're planning on a release of this early to mid August, giving users some goodies before TRiBot X's release.

      Thank you all for being patient. I hope everyone is excited as much as I am!
        • Like
      • 17 replies
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...