- Joined
- Nov 3, 2013
- Messages
- 609
- Thread Author
- #1
Hi guys, I looked around the forums but couldn't find any tutorials or even an explanation of the newish TreeBot class and seeing as I wrote it, I figured I might as well write up an explanation of the logic.
[WORK IN PROGRESS WILL BE UPDATED LATER]
This thread is meant to not only inform, but also convince you to switch over your current bots to the new API. So if you've been debating converting but don't know where to start, or if you had no idea this was even a thing, sit down for a minute and read this, and hopefully by the end you will be ready and wanting to convert your Bots to this new powerful methodology.
1. What's wrong with LoopingBots?
While is perfectly possible to implement a working bot on this platform, there is a conflict in how humans think and how the machine thinks. The issue that many authors run into here, is they try to perform multiple actions during a single loop iteration. This may not seem like a problem at first, but what you need to consider is the volatile state of Runescape. Things are always changing. For example consider trying to decant potions, to do this, you might use your potion on the NPC.
To a human this will seem as if it is one or two actions, but from a bot standpoint, it is actually several:
1. Verify Inventory is open
2. Right click potion
3. Select Menu option
4. Click on NPC
A novice programmer may try to perform this as one action. They may in fact find the NPC before clicking the potion, however when they finally get around to clicking the NPC, it's 300ms later and he has moved. (I don't think that NPC does move, but for the sake of example, assume he does). So now your bot has more potential to misclick. This was all caused by outdated information, which could have been solved by querying for the state of the game before every input.
Looking at this, you might be like "Fine, I'll just gather all of the information that I need every loop iteration, then make one action". This will solve the issue to some extent, but you have to remember that even though the decision made by the computer is near instantaneous, it is only "near" and still takes time. This means that data gathered should be as close to the action as possible, which can be implemented in a LoopingBot with a massive if/else if/else block as seen here in this loop function:
Exia-Mining-All-In-One/StandardMiner.java at master · JohnRThomas/Exia-Mining-All-In-One · GitHub
While this works, it's not very nice to think about and can be difficult to find exactly what action you are looking for. Also it just ends up being an implementation of the TreeBot without the nice wrapper and clarity the TreeBot platform provides.
2. What's wrong with TaskBots?
The TaskBot was a good attempt at solving the main issue of LoopingBots, that is, it forces the author to perform a single action per loop iteration. The issue with it though, is that it limits the author by forcing them to over validate situations. Because it can only perform an action when a validator is true, this simply throws away information. If you have a boolean condition, by the nature of it, it only has two states. So if I'm checking whether or not the inventory is full, I should not have to also check if it is not full too. The TaskBot forces you to do this.
The TaskBot also falls short when you consider action ordering. Action ordering can be inferred, but it cannot be enforced, which is very limiting to the author when you realize that each action is decided by a string of validated information, and not just by a single validator. What do I mean when I say it cannot be enforced? I mean that while you know all of the previous validators have evaluated to false, you don't know if there are any further validators that would run after your current validator that would reduce ambiguity of the state even further. And yes, you can finagle the ordering of the validators to get it to work, but you shouldn't have to. There should be an explicit way of ordering the validators and tieing a task to each one's evaluation, whether true or false.
3. What is the TreeBot?
First off you'll need to know what a tree is, so read up here:
Tree (data structure) - Wikipedia
Binary tree - Wikipedia
Binary search tree - Wikipedia
Assuming you understand a binary search tree, then you understand the TreeBot, because it's actually just a slightly modified binary search tree. The key to this implementation, is that you are searching for the desired action using the state of that game as input, and instead integer comparisons, it will be using validators to traverse either right or left on the tree. The other thing you need to know is that each action must reside in a leaf node of the tree. That's really all you need to know.
4. How does the TreeBot solve the problems of TaskBot?
First let me explicitly identify the three issues with the TaskBot:
1. Validators result in two states, but you can only act off of one of them forcing double validation of test and NOT test.
2. No multiple validation of actions. Imagine writing a program with no AND or OR operator, it's possible, but takes extra work.
3. No explicit ordering of validators based off previous evaluations.
-----
These are all solved basically by the nature of a tree.
1. Solved because each validator has two children, meaning you can use both paths after a single validation.
2. This is hard to explain, but basically it comes down to using the structure of the tree and only testing validators in order.
3. This is solved by the parent and child relationship structure of each node. Very similar to #2
5. API explanation of classes
So first off, you can check out the API here. There are four classes that you need to know about:
1. TreeBot
2. TreeTask
3. BranchTask
4. LeafTask
6. Examples
This github repository holds a couple of example implementations on how to make a very simple bot that will withdraw a banana for you.
GitHub - MihaelBercic/TreeBot: An example for scripters
7. Tips
TODO: Talk about balancing trees
Let me know if you have any questions or want me to talk about anything specific.
[WORK IN PROGRESS WILL BE UPDATED LATER]
This thread is meant to not only inform, but also convince you to switch over your current bots to the new API. So if you've been debating converting but don't know where to start, or if you had no idea this was even a thing, sit down for a minute and read this, and hopefully by the end you will be ready and wanting to convert your Bots to this new powerful methodology.
1. What's wrong with LoopingBots?
While is perfectly possible to implement a working bot on this platform, there is a conflict in how humans think and how the machine thinks. The issue that many authors run into here, is they try to perform multiple actions during a single loop iteration. This may not seem like a problem at first, but what you need to consider is the volatile state of Runescape. Things are always changing. For example consider trying to decant potions, to do this, you might use your potion on the NPC.
To a human this will seem as if it is one or two actions, but from a bot standpoint, it is actually several:
1. Verify Inventory is open
2. Right click potion
3. Select Menu option
4. Click on NPC
A novice programmer may try to perform this as one action. They may in fact find the NPC before clicking the potion, however when they finally get around to clicking the NPC, it's 300ms later and he has moved. (I don't think that NPC does move, but for the sake of example, assume he does). So now your bot has more potential to misclick. This was all caused by outdated information, which could have been solved by querying for the state of the game before every input.
Looking at this, you might be like "Fine, I'll just gather all of the information that I need every loop iteration, then make one action". This will solve the issue to some extent, but you have to remember that even though the decision made by the computer is near instantaneous, it is only "near" and still takes time. This means that data gathered should be as close to the action as possible, which can be implemented in a LoopingBot with a massive if/else if/else block as seen here in this loop function:
Exia-Mining-All-In-One/StandardMiner.java at master · JohnRThomas/Exia-Mining-All-In-One · GitHub
While this works, it's not very nice to think about and can be difficult to find exactly what action you are looking for. Also it just ends up being an implementation of the TreeBot without the nice wrapper and clarity the TreeBot platform provides.
2. What's wrong with TaskBots?
The TaskBot was a good attempt at solving the main issue of LoopingBots, that is, it forces the author to perform a single action per loop iteration. The issue with it though, is that it limits the author by forcing them to over validate situations. Because it can only perform an action when a validator is true, this simply throws away information. If you have a boolean condition, by the nature of it, it only has two states. So if I'm checking whether or not the inventory is full, I should not have to also check if it is not full too. The TaskBot forces you to do this.
The TaskBot also falls short when you consider action ordering. Action ordering can be inferred, but it cannot be enforced, which is very limiting to the author when you realize that each action is decided by a string of validated information, and not just by a single validator. What do I mean when I say it cannot be enforced? I mean that while you know all of the previous validators have evaluated to false, you don't know if there are any further validators that would run after your current validator that would reduce ambiguity of the state even further. And yes, you can finagle the ordering of the validators to get it to work, but you shouldn't have to. There should be an explicit way of ordering the validators and tieing a task to each one's evaluation, whether true or false.
3. What is the TreeBot?
First off you'll need to know what a tree is, so read up here:
Tree (data structure) - Wikipedia
Binary tree - Wikipedia
Binary search tree - Wikipedia
Assuming you understand a binary search tree, then you understand the TreeBot, because it's actually just a slightly modified binary search tree. The key to this implementation, is that you are searching for the desired action using the state of that game as input, and instead integer comparisons, it will be using validators to traverse either right or left on the tree. The other thing you need to know is that each action must reside in a leaf node of the tree. That's really all you need to know.
4. How does the TreeBot solve the problems of TaskBot?
First let me explicitly identify the three issues with the TaskBot:
1. Validators result in two states, but you can only act off of one of them forcing double validation of test and NOT test.
2. No multiple validation of actions. Imagine writing a program with no AND or OR operator, it's possible, but takes extra work.
3. No explicit ordering of validators based off previous evaluations.
-----
These are all solved basically by the nature of a tree.
1. Solved because each validator has two children, meaning you can use both paths after a single validation.
2. This is hard to explain, but basically it comes down to using the structure of the tree and only testing validators in order.
3. This is solved by the parent and child relationship structure of each node. Very similar to #2
5. API explanation of classes
So first off, you can check out the API here. There are four classes that you need to know about:
1. TreeBot
Description:
This is the base class that holds the tree. Do all of your normal things like a gui here.
Methods:createRootTask - This is where you create you tree. Whether you chose to return a static tree that is defined at compile time, or build one in this function based on GUI input or game version is up to you. The only thing that you need to worry about is making sure none of your task nodes are null.
2. TreeTask
3. BranchTask
4. LeafTask
6. Examples
This github repository holds a couple of example implementations on how to make a very simple bot that will withdraw a banana for you.
GitHub - MihaelBercic/TreeBot: An example for scripters
7. Tips
TODO: Talk about balancing trees
Let me know if you have any questions or want me to talk about anything specific.
Last edited:
