The idea of learning about a binary search tree is to get the author "Balance" their tree in a similar way. If you can make the height of the tree minimal, and keep the most often traversed paths close to the root, you will have a bot that is doing less busy work. This leads to faster reaction times and all that jazz.
For more sophisticated scripts bots I've always thought a stack data structure would work best, where the highest-priority task is popped from the top of the stack and executed. You could set it up to push prerequisite tasks if required, and push successive tasks once executed.
Determining the highest priority task that meets all conditions for that task to run would likely take more resources and time to determine than using a binary decision tree.
It's a stack so by design the highest priority task is at the top, if a stack was an inefficient data structure then your CPU wouldn't be very fast (stack registers). Also it is irrelevant as to how efficient/inefficient the script bot task data structure is since that's no-where near the bottleneck for the bot client.
Doesn't this client use RMI for interaction between the process where the script bot runs and where the RS JVM is? That would dominate, the data structure you use for your scripts bots has so little overhead compared to that it's not even worth thinking about. Yeah I think it would be kinda cool to try out, especially for something like a questing bot.
You can design your treebot in a 'high priority' structure. Treebot should/can pretty much encompass all that you need in regards to that (for majority of scenarios - especially quests since those are very very linear).
A TreeBot would be a terrible framework for building a questing bot on since internally RS handles quest progress with varbits. You'd end up with a linear binary tree (defeating the entire purpose of the TreeBot framework). I'd argue one of those "state based" bots new developers seem to love would be the best for this and then each "state" logic could be handled by whatever execution mechanism your heart desires. Actually @Ian C this would be an awesome use case for your FSM bot.
Actually no it wouldn't be a terrible setup for a questing bot. You can handle varps and varbits via a treebot..? Yes it would be linear progression (aka unbalanced tree) but it is do-able and a non-balanced tree isn't that big of a deal with smaller/simpler bots. Runtime difference would be negligible if noticeable at all. I wasn't recommending a best case, basically just saying treebot can encompass all of what he is looking for and works, including for 'high priority' situations. Yep FSM would work as well, arguably better if you're relying solely on varp/varbit values. But since it isn't documented on jdocs yet, i'm gonna stay away from recommending it to a newer poster
A deterministic finite automaton would be a more precise term if every node were to have a binary success/failure like you mention.
