Adding a 'Task Manager' or 'Task System' to your Script.

[ArmyofDragons 28]

Hello everyone. This is my first tutorial and I am writing this at almost 4am, so bear with me.

 

This tutorial will not contain 'free' code as this is a 'base' task system / task manager. I have a more complex one that has prioritizing and other features.

You, yourself, could add onto it if you would like, but I ask you to do it with your own knowledge / capability. Copy-pasting is a no-no.

 

 

 

Task Manager / Task System

 

Written by ArmyofDragons

 

 

 

In this tutorial I will show you how to create a simple, clean, and effective Task Manager for your DreamBot Script.

The only requirements for following this tutorial is having a decent knowledge of programming and an open mind.

 

 

 

I. Setting up your Script (the easiest part)

I am only showing this for the purpose of making the tutorial flow. Obviously you should know by now how to create a Script. You can use TaskScript here as well, but I decided to use the default AbstractScript provided in the API.

 

 

II. Creating the Task Manager-Task Class & Interface

Here we will create a Class and an Interface -- The Class representing our TaskManager, the interface representing our base 'Task' implementation. You do not need to write these inside your Script class. If you decide to write them as separate Classes / Interfaces -- make sure you pass an instance of the MethodContext and Client to the Tasks (this would require Task being an Abstract Class instead with the proper constructors). This would allow you to get full access to all of the functionalities of Dreambot's in-game methods.

 

 

III. Task Manager Class

Here we will set up a Class to represent our Task Manager. The TaskManager will hold all of our Tasks and run them when necessary.

 

 

IV. ITask Interface

We are creating an interface to use for implementation for our Tasks. Here, ITask will represent our Task with two basic functionalities: notifying us if we are ready to execute, and a method representing the Task's executable code. This leaves the mess and unnecessary need to create an Abstract Class to represent a Task. It does not really matter, but an Interface is preferred here for the essence of simplicity.

You can make this an Abstract Class instead and add constructors to pass in instances of Client & MethodContext, however this will not be shown in this tutorial, as I have written the TaskManager Class and ITask Interface nested inside the Script class (so you can call getClient(), etc. without hassle)

 

 

V. Giving the Task Manager its Functionality

Here I am simply looping through all available Tasks and finding the first one that can be executed. Unless you want your script to be designed to run multiple Tasks at a time, I suggest including the 'return' in the TaskManager poll() method.

 

 

VI. Creating our own Task

Treat the canExecute() method implemented from our ITask interface in the logic that the Task will be run if conditions are met (return true) for your Task.

-

-

 

VII. Implementing our Task Manager into our Script

This can be done however you want it to be; I am doing this in a simple way to provide an example.

-

 

VIII. Adding Tasks

Here I have added my newly created "AttackTask" into the TaskManager's ArrayList of ITasks. Add as many as you would like in the order you want your tasks to be run. (i.e. WALK_TO_AREA -> ATTACK_NPC -> LOOT -> EAT -> WALK_TO_BANK, etc.)

 

IX. We are done! It is up to you to finish.

 

My example only had one task -- obviously you would have more for whatever script you have in mind.

 

Add more flavor to the skeletons provided in this tutorial, such as:

- Task Prioritizing (sorting the Tasks by priority, or importance)

- Adding / Removing Tasks (for complex scripts requiring such)

- Canceling Tasks (for scripts that require lengthy tasks, or for other reasons, obviously)

 

 

 

My example did not provide the meta 'script state' implementation (as in an Enum for the script's states). This was intentional.

 

Using the above 'Task Manager' example shown in the tutorial, you can extend out and add multiple different functionalities to your script. This enables you to have the power of reducing clutter and large hard-coded functions sprawling throughout your script.

 

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

 

I hope you guys enjoyed my tutorial; thanks for reading!

 

If there are any typos, errors, or false claims/statements, it is most likely due to me not being fully awake. Oh well.

 

Tomorrow I will add more Task examples (TaskFighting, TaskLooting, etc)

[Articron 738]

I'm not sure as to why you would make nested classes for this?

 

Edit: You have the right idea though, good job

[distraction 61]

Why not just use `TaskScript` instead of `AbstractScript`? You can also use `TaskNode` instead of creating your own interface for the tasks / nodes. You would also probably want to pass client to your tasks / nodes and register the method context.

 

Just to be clear, I do applaud your effort to make a tutorial to help people and I do think you did a good job of explaining the setup.

[Articron 738]

Why not just use `TaskScript` instead of `AbstractScript`? You can also use `TaskNode` instead of creating your own interface for the tasks / nodes. You would also probably want to pass client to your tasks / nodes and register the method context.

 

This. Or you could create an environment object which contains both Dreambot's MethodContext and your own API and pass those along in the parameters of your nodes. This is how I personally do it

[ArmyofDragons 28]

I'm not sure as to why you would make nested classes for this?

 

Edit: You have the right idea though, good job

 

Because it's a tutorial. The point was that I wrote it at 4am and just wanted to make it as concise as possible in terms of what a Task Managing 'system' would look like.

 

There is also no harm in using nested classes aside from OOP conventions and whatnot. I just wanted everything to be in one class to easily showcase in the tutorial.

Nested classes are never an issue in any case imho. Considering this script is about under 100 lines of code, it causes no issue.

Why not just use `TaskScript` instead of `AbstractScript`? You can also use `TaskNode` instead of creating your own interface for the tasks / nodes. You would also probably want to pass client to your tasks / nodes and register the method context.

 

Just to be clear, I do applaud your effort to make a tutorial to help people and I do think you did a good job of explaining the setup.

 

I agree with you here. I've looked into the API a lot and I have seen TaskScript, I just don't use it unless needed. Thanks for pointing out 'TaskNode', though. I made this tutorial based on others asking for a tutorial on it, so having one that shows how to make your own complete Task / TaskManager was sufficient in my opinion.

 

The point of this tutorial was not to spoonfed (that's why I used screenshots) and encourage people to do it their own way. It's just a skeleton of what can be done.

 

Passing an instance of the client is a good idea, however I did not use it in my example as it can be accessed simply by calling getClient() since everything is nested inside the TutorialScript Class.

 

---

 

I appreciate the responses guys. As I have put in the bottom of the OP, I will be updating it soon when I am fully awake and not busy.

[Articron 738]

Because it's a tutorial. The point was that I wrote it at 4am and just wanted to make it as concise as possible in terms of what a Task Managing 'system' would look like.

 

There is also no harm in using nested classes aside from OOP conventions and whatnot. I just wanted everything to be in one class to easily showcase in the tutorial.

Nested classes are never an issue in any case imho. Considering this script is about under 100 lines of code, it causes no issue.

 

 

Please don't take this the wrong way because I have zero intent on attacking you, BUT

 

1. The Dreambot API in itself is written in an OOP way meaning it would be more sensible to have them adapt to those conventions.

2. Nested classes contradict your point of better readability. Seperation of classes not only make everything better on the eye, I think you will find very few established developers that write an application in a singular class.

3. The latter is especially true when you start nesting your ITask implementations. It doesn't stimulate clarity but instead - to put it quite frankly - will end up as more of a clusterfuck than regular enumeration states would.

 

To me personally, being able to juggle around the MethodContext is one of the most important entry points as a Dreambot scripter.

 

Another point, although it's quite nitpicky, is that you aren't utilising java 8 features.

 

I would like, however, to echo what I said before: your help to the community is greatly appreciated and I hope you understand that I'm not trying to break you down.

I'll be eager to see what your tutorial turns into once you rewrite it

[ArmyofDragons 28]

Please don't take this the wrong way because I have zero intent on attacking you, BUT

 

1. The Dreambot API in itself is written in an OOP way meaning it would be more sensible to have them adapt to those conventions.

2. Nested classes contradict your point of better readability. Seperation of classes not only make everything better on the eye, I think you will find very few established developers that write an application in a singular class.

3. The latter is especially true when you start nesting your ITask implementations. It doesn't stimulate clarity but instead - to put it quite frankly - will end up as more of a clusterfuck than regular enumeration states would.

 

To me personally, being able to juggle around the MethodContext is one of the most important entry points as a Dreambot scripter.

 

Another point, although it's quite nitpicky, is that you aren't utilising java 8 features.

 

I would like, however, to echo what I said before: your help to the community is greatly appreciated and I hope you understand that I'm not trying to break you down.

I'll be eager to see what your tutorial turns into once you rewrite it

 

I don't take anything on the internet as 'attacking', however I find it quite weird for you to be questioning every little detail, as if using or implementing certain features would make a big difference. (Unless it is in terms of speed -- which you are not even mentioning)

 

I am aware of Java 8 features and I use them all the time; this is a simple tutorial that was written at 4am in the morning without any sense of looking over every single detail. The usage of Java 8's new features does not make a programmer better or worse; nor their code. If you are talking about my lack of Lambda Expressions, it would barely make a difference imho.

 

Please, and I ask respectfully, show me where it is harmful using 2 nested inner classes on a damn tutorial/example. Unless I am writing a full-fledged top to bottom API/Library of a Task System / Manager for scripts (which I do have privately, not to brag) -- then I will not care for harmless practices of programming.

 

In response to your points:

 

"The Dreambot API in itself is written in an OOP way meaning it would be more sensible to have them adapt to those conventions."

1. Anything that is object-oriented (which is literally my tutorial) -- is practicing OOP. First off, I am using inner classes -- not nested classes. Java defines a 'nested class' as a static class within a class. Inner classes is a form of OOP, so your statement/claim is invalid. If I was using nested static classes, it would be different. The point of using nested classes (which does not derail from the OOP conventions in any way; many APIs and Libraries use nested classes for various purposes and programmatic reasons) can be found in various circumstances, however I do not need to sit and explain why my tutorial that took 5 minutes to write needs to be to your own liking. (Yes, code should be written in a way that should be understood by a body of people who will view/use that code, but this is not my full intent)

 

"Nested classes contradict your point of better readability. Seperation of classes not only make everything better on the eye, I think you will find very few established developers that write an application in a singular class."

2. Ugh. I'm sorry for being rude, but do you read anything I have said? I understand you are trying to give your input but it's as if you are not even giving proper criticism/input in this post. First off, as I explained in #2, nested classes are static classes enclosed in another class -- inner classes are non-static (nested) classes (classes that can be instantiated) within another class. (It's weird because nested classes can be static/non-static, but non-static have a certain term for them) Second, as I explained multiple times, the point of me using inner classes is to make the tutorial less cluttered (by less cluttered I mean not writing a full on script that actually works) and not use as many screenshots. I clearly stated in the tutorial that it is suggested that one should obviously not do what I did in the example. 

I honestly don't understand why you think it is necessary to complain about every single little thing. You can literally go into Java's own libraries and find multiple examples of questionable and unorthodox meanings of implementation. It's as if it hurts you for me to use inner classes rather than separate ones (which a simpleton can do if they know OOP) when it's a tutorial slapped up in 5-10 minutes late at night.

 

"The latter is especially true when you start nesting your ITask implementations. It doesn't stimulate clarity but instead - to put it quite frankly - will end up as more of a clusterfuck than regular enumeration states would."

3. I am not writing an API that is for public use; I am not writing or sharing my own code that I use myself -- this is a tutorial on how to develop a specific functionality for one's own scripts, moreover a workaround rather than a copy-and-paste tutorial.

Having 2-3 nested inner (non-static classes) in a class for an example/tutorial is not going to hurt anyone. (I hope not)

Another specific reason why I am using inner classes is not for 'readability' (lol) but rather to show a direct implementation of it and encourage my readers to do it in their own form. I am not going to spoonfeed a complete TaskManager implementation in the 'perfect' form for everyone to use because it's merely a tutorial to show a concept; not fully implement and use the concept.

 

And to be fair (and this is for all of my responses to your points) -- the majority of scripts on botting websites are not written in the proper Java programming conventions. I've seen many tutorials on here showing bad practice and just absolute retardation in regards to how they write their self-proclaimed 'high quality' scripts.

I have even decompiled scripts in the past out of curiosity and have found that they just throw all of their shit in a 1,000+ lines of code class and call it 'high quality' and created 'to the standards'.

 

As this is the internet, I do appreciate the attempt at honest criticism, however you seem to be swinging and missing on some of your points. You did however show some other good points previously in your other posts; this one... not so much. If I intend to come off as 'salty' or 'rude' -- no worries, I am not trying to be.

 

To clear things up, I do support clean and organized code (yeah, yeah, shoot me) -- if you have learned programming at a college/university your professors may have always said the statement "Programmers are very lazy" in the aspect that writing, say, a quick script to do simple, mundane tasks shouldn't be organized and absolutely 'clean' (i.e. not hard-coded) -- as long as it is efficient and it gets the job done, then the price is right. Obviously this wouldn't be the slogan for any software developer. (don't understand why you are bringing up software development companies on a botting forum, but I guess that's how you look at it)

 

All programmers do things differently -- regardless if they work at X software development company, or are studying at X university in the top Computer Science programs -- I have seen my own fellow classmates at my university struggle in certain areas of programming (there is NO such thing as a 'perfect' programmer, nor will there ever be); even your own professors may do something weird. (When I was learning Scala my professor showed us how to do sorting and whatnot and loved to do one-liners of his sorting algorithm examples)

 

Also:

 

"To me personally, being able to juggle around the MethodContext is one of the most important entry points as a Dreambot scripter."

 

I have not put the API to its full use anywhere in my tutorial, as I have not put in the time to look over it completely. And as I have mentioned earlier, I do fully appreciate your input.

 

Anyways, I will be updating the tutorial regardless -- I will, however say that as much as I appreciate the input, I do not see a purpose in the complaining of every single small detail or lack of one Java 8 feature (lmao). 

[Dinh 496]

LONG QUOTE

Calm down sir, people are not attacking you, they try to help you to improve your code!

[Almonds 110]

This a great template for many people still learning! (including myself)

The guide is very easy to read and work through-

thanks!

[ArmyofDragons 28]

Calm down sir, people are not attacking you, they try to help you to improve your code!

 

It's a long post to constructively respond to the guy, not a 'lash' or taking offense. If you even read my post, I said that I am just responding in a respective manner.

This a great template for many people still learning! (including myself)

The guide is very easy to read and work through-

thanks!

 

 

No problem. More tutorials will come for sure. That also reminds me, I should update this tutorial sometime soon.