[exia]

It actually isn't a binary search tree. It is just a binary tree. Suggesting that someone learn a binary search tree is really overcomplicating the problem. In reality a tree bot is just a looping bot with each the if/elses replaced by tree nodes which just improves maintainability.

Overall, a good tutorial on how to make a decision tree though.

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.

 

[sam]

For more sophisticated scripts 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.

 

[proxi]

For more sophisticated scripts 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.

 

[sam]

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 task data structure is since that's no-where near the bottleneck for the bot client.

 

[proxi]

Also it is irrelevant as to how efficient/inefficient the script task data structure is since that's no-where near the bottleneck for the bot client.

That's incorrect.

 

[serene]

For more sophisticated scripts 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.

I've seen other clients do this. You can still do this with the structures that are setup here

 

[sam]

That's incorrect.

Doesn't this client use RMI for interaction between the process where the script runs and where the RS JVM is? That would dominate, the data structure you use for your scripts has so little overhead compared to that it's not even worth thinking about.

I've seen other clients do this. You can still do this with the structures that are setup here

Yeah I think it would be kinda cool to try out, especially for something like a questing bot.

 

[serene]

Doesn't this client use RMI for interaction between the process where the script runs and where the RS JVM is? That would dominate, the data structure you use for your scripts 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).

 

[aydex]

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.

 

[serene]

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

 

[daniel]

For more sophisticated scripts 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.

Hello Sam yes what you doing
When are you getting unbanned
Also why BST and not AVL

 

[sinning]

Great post, mate. Everyone should be using treebots.

 

[dungeonqueer]

A deterministic finite automaton would be a more precise term if every node were to have a binary success/failure like you mention.