[qosmiof2]

GitHub - MihaelBercic/TreeBot: An example for scripters

If i am wrong anywhere please let me know to fix it up.

 

[savior]

You really shouldn't create new instances in failureTask and successTask. Think about it, this will lead into multiple new objects per second depending on the complexity of the bot.
Also there are already subclasses of TreeTask that you should use.
And the visualization of the tree in the README is a bit off.

Edit: All in all this example is a bit too small in order for new developers to understand the advantage of TreeBot, both the theoretical and practical way.

 

[qosmiof2]

You really shouldn't create new instances in failureTask and successTask. Think about it, this will lead into multiple new objects per second depending on the complexity of the bot.
Also there are already subclasses of TreeTask that you should use.
And the visualization of the tree in the README is a bit off.

Edit: All in all this example is a bit too small in order for new developers to understand the advantage of TreeBot, both the theoretical and practical way.

You are right. Ill fix it right now.

 

[firefoxes]

Advantages could be understood from Exia's tutorial. I need a starting point, and this example looks like exactly what i need. Thanks a lot!

 

[qosmiof2]

Advantages could be understood from Exia's tutorial. I need a starting point, and this example looks like exactly what i need. Thanks a lot!

You really shouldn't create new instances in failureTask and successTask. Think about it, this will lead into multiple new objects per second depending on the complexity of the bot.
Also there are already subclasses of TreeTask that you should use.
And the visualization of the tree in the README is a bit off.

Edit: All in all this example is a bit too small in order for new developers to understand the advantage of TreeBot, both the theoretical and practical way.

Updated and fixed. I expanded the script.

 

[exia]

Thanks for making this. I'm going to use it as my example for balancing trees. Also I think there is a bit cleaner way to build the tree using lambda functions that doesn't require as many files. I think it's the perfect size for a springboard example just to get author's feet wet.
 
Also, I forked your repo and I'm gonna commit some stuff later today: An example using enums and one asing anonymous classes. I think I'm also going to restructure the folders a bit.

 

[mad]

When is successTask() and failureTask() executed? Doesn't say anywhere in the code

Edit: nvm read the api docs, makes sense, but this isn't really much different than the node framework with parent / child relationships.

 

[savior]

When is successTask() and failureTask() executed? Doesn't say anywhere in the code

Edit: nvm read the api docs, makes sense, but this isn't really much different than the node framework with parent / child relationships.

The difference is that the TreeBot framework allows an easier setup of a balanced binary tree, which is far more efficient than the TaskBot system.

 

[exia]

I added an example implementation using enums to define the branches and leaves. Hopefully @Qosmiof2 will pull them into his repo soon, if not, feel free to check out my fork.

 

[savior]

I added an example implementation using enums to define the branches and leaves. Hopefully @Qosmiof2 will pull them into his repo soon, if not, feel free to check out my fork.

Having task instances in enums? really?

 

[qosmiof2]

I added an example implementation using enums to define the branches and leaves. Hopefully @Qosmiof2 will pull them into his repo soon, if not, feel free to check out my fork.

Didn't really check what you did just pulled it. Ill check them later.

 

[exia]

Having task instances in enums? really?

Yes, with a little bit of helper code, each file is only about 30-40 lines of code for this simple example. For static trees (ones that will never have any nodes swapped based on the game type or anything else) it works very well and is cleanly readable. Check it out now that it was pulled into the repo

 

[savior]

Yes, with a little bit of helper code, each file is only about 30-40 lines of code for this simple example. For static trees (ones that will never have any nodes swapped based on the game type or anything else) it works very well and is cleanly readable. Check it out now that it was pulled into the repo

Mind that when a user runs multiple bots that use these tasks, there may be intereference if the classes have any fields to cache game objects.

 

[exia]

Mind that when a user runs multiple bots that use these tasks, there may be intereference if the classes have any fields to cache game objects.

I thought RM used different VMs for each bot instance, which is how the API is static in the first place.

 

[savior]

I thought RM used different VMs for each bot instance, which is how the API is static in the first place.

No runemate uses one jvm. When making a static api call, the corresponding bot instance is looked up using the thread as an identifier, that's why you can only call most api methods on the bot's thread, or any thread associated with it.

 

[exia]

No runemate uses one jvm. When making a static api call, the corresponding bot instance is looked up using the thread as an identifier, that's why you can only call most api methods on the bot's thread, or any thread associated with it.

I think that since all of the calls are going to end up being to the API in the end, they will originate from the caller's thread id like normal. It's really just storing a reference to the enum's task, and if you look at the example, it's a very simple one that doesn't store any data in the Task objects at all. The given example would work as intended, and it will work for very simple tree structures; I can see that you would be correct about more complex bots if they are trying to have persistent storage. I'm working on a second example in the "dynamic" directory that works entirely different and will be for complex bots. If you have an example, it would be great if you could fork that repo and add it too

 

[savior]

I think that since all of the calls are going to end up being to the API in the end, they will originate from the caller's thread id like normal. It's really just storing a reference to the enum's task, and if you look at the example, it's a very simple one that doesn't store any data in the Task objects at all. The given example would work as intended, and it will work for very simple tree structures; I can see that you would be correct about more complex bots if they are trying to have persistent storage. I'm working on a second example in the "dynamic" directory that works entirely different and will be for complex bots. If you have an example, it would be great if you could fork that repo and add it too

I am not concerned about the threads, I am concerned about the tasks being static.

Ideally your bot would be optimized to only access the game data once per loop, so if a branch looks for a certain item to interact with, the following leaf should use that very instance of the branch task, instead of querying for the item a second time. In order to achieve this, you would need to pass the reference to the leaf somehow, and it's very easy to mess it up, resulting in all your running bot instances using the same spriteitem later on.

Static/enums should only be used for truly constant data, that behaves constantly the same and can't be changed during runtime.

 

[driftson]

Thank you