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

Sell OSRS Gold

Wastedbro

Developer
  • Content Count

    2,780
  • Joined

  • Last visited

  • Days Won

    48
  • Feedback

    100%

Wastedbro last won the day on June 17

Wastedbro had the most liked content!

Community Reputation

776 Excellent

About Wastedbro

  • Rank
    TRiBot King
  • Birthday 11/30/1995

Personal

  • Sex
    Male

Recent Profile Visitors

9,325 profile views
  1. I just tested log dropping. It works fine for me. I'm not sure what the issue is but I believe it's either on your end or something to do with the tribot client itself (not my script). As for log burning, it's not perfect. Some tiles won't let you make fires on them. I assure you that there is absolutely nothing random about the tile it picks. It always picks the closest tile that can have a fire on it. I'll look into the varrock east thing.
  2. It won't. The paint doesn't translate images or do any calculations. Disabling it won't make a difference. This is true for most paints, too.
  3. 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.
  4. Update [Version 2.35] Made it so the script will exit out of the bank tutorial interface on new accounts Increased the cost of teleporting in Daxwalker so that the script will opt to teleport less over just walking. @lau1992 Was that a one-time thing or is it still happening?
  5. Tribot does not support external libraries. Also, the Tribot API uses threading and heavy use of thread sleeping, which does not play nicely with coroutines at all. I doubt you'll find much use in using coroutines in your script. You'll have to trust me when I say that, because I love Kotlin coroutines.
  6. You should look into Kotlin's type-safe builders, which allow you to create DSL-like syntax APIs. Here is an example of my behavior tree framework in action: This is all valid Kotlin code, and it produces an object which can be executed. The object is a behavior tree. My framework for this is open source, but not much documentation: https://gitlab.com/WBScripting/kbehaviortree It's based off of behavior trees, which can be described here: https://www.gamasutra.com/blogs/ChrisSimpson/20140717/221339/Behavior_trees_for_AI_How_they_work.php Here is the java equivalent: https://gitlab.com/WBScripting/behavior-tree-framework And here is a Decision Tree Framework in Java, which also uses functional programming: https://gitlab.com/WBScripting/binary-decision-tree-framework Feel free to look into those and see if your framework here can benefit from them, or vice versa.
  7. 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.
  8. 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.
  9. 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 A server is a system that accepts connections A client is system that attempts to connect to a server A 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.
  10. Update [Version 2.33] Fixed a rare bug where the uptext of using a log caused banking to get stuck Fixed a bug where if the script would missclick onto a boat in the port sarim docks, it would be stuck I took a look at the distances. You're right, it's faster. I can't promise I'll be able to do this soon, but I'll make a note of it. It will require a decent amount of change, because the bank chest also serves as a way to ensure your character is using the best axe, has all its money in inventory, etc.
  11. Update [Version 2.31]: Fixed an issue where the script would sometimes target trees that it could not reach Fixed an issue where the script would not close out of the "report player" interface if it got accidentally opened
  12. It's unlikely that a VPS would work with an Android Emulator. VPS's are already virtual devices (the V in VPS). Running virtual devices inside of virtual devices generally doesn't work.
  13. This script supports those locations. If there is no preset, you can use the custom location feature. Also, as most scripts, this one has a free trial. I suggest you use it next time. Refunded.
  14. 1. Yes, you need USB or Bluetooth. You can technically hook up ADB through wifi or even through the internet, but that won't work with Tribot Mobile for reasons I won't go into. 2. Theoretically anything should work as long as it runs OSRS. Some will work better than others but only time will reveal what works best. 3. That is nonsense that other mobile bot devs peddle because they are notorious for writing shitty autoclickers that get banned. The most common ways for an app to look for emulators is through system variables like build and manufacturer. Of course, these are unreliable, and even if Jagex risked using them, they can easily be spoofed (some emulators already do so). Outside of that, you'd need to create a system that profiles devices and heuristically calculates the probability based on hardware/software analysis that you can access via app development. Obviously not something Jagex does, nor is likely they ever would.
×
×
  • Create New...