TaskScript Framework for state-based scripting

[Frozen-tuna]

#1416

Figured I'd start the discussion here. This PR includes two new classes, one of which extends the Microbot Script class. This can help developers write cleaner scripts and encourages abstracting out responsibilities into individual files. Instead of having a large switch statement and a function to determine an enum for which state we're in, a series of tasks can determine which state we're in. For example, a script that crafts water orbs could have the following Tasks declared in Plugin :

new FirstBankTask(),
new FaladorBankingTask(),
new WalkToDragonsTask(),
new RunToObeliskTask(),
new EnchantWaterOrbsTask()

While developing, this simplifies the responsibilities of each task and makes the code easier to read. This is also how most Dreambot scripts are written. There also exists a branch-leaf architecture that abstracts this a layer further but I personally don't think that's necessary at this time. An example herb farming script would look like the following:

new StartingBankBranch().addLeaves(new StartingBank(), new PreCanafisBank()),
new FarmEctoBranch().addLeaves(new FarmEcto()),
new FarmCatherbyBranch().addLeaves(new TeleportCamelot(), new FarmCatherby(), new PreArdougneBank()),
new FarmFortisBranch().addLeaves(new TeleportFortis(), new FarmFortis()),
new FarmArdougneBranch().addLeaves(new TeleportArdougne(), new FarmArdougne()),
new FarmFaladorBranch().addLeaves(new TeleportFalador(), new PreFaladorBank(), new FarmFalador()),
new FarmHosidiusBranch().addLeaves(new TeleportHosidius(), new FarmHosidius()),
new TravelGuildBranch().addLeaves(new TravelFairyring())

Again, not really suggesting we jump on this one nor is it in the PR above.

To use this, each task has the following two functions: accept() and execute().

accept() returns a boolean for when that task should run. execute() is what the script will do while plugin is running for a single loop and returns a value of time to be waited before the next loop. An example of a task that runs once and does nothing:

Boolean hasRun = false;

public boolean accept() {
    return !hasRun;
}

public int execute() {
   hasRun = true;
   return (int) (Math.random() * 401) + 2400;
}

[gmason0]

Hey !

I just wanted to let you know that I haven't forgot about this - our plugin hub feature has just been taking alot of my time.

Personally, I do not want to directly rip-off dreambot's framework, and rather we take our own spin to it. We have been bashed before in the past for people attempting to take ideas from other places. so I figured lets save face now before we get too ahead of ourselves...

https://github.com/g-mason0/Microbot/tree/feat/step-manager

Here is what i've come up with thus far, I still need to finish up the docs & create some more abstract steps: but this works mostly the same outside of a few different things.

1. I am not a big fan of execute returning an int. All sleeps i feel should be encapsulated within that current step. Not returned & inside of the abstract loop. It makes it hard to say which step is sleeping & how long.
2. This doesn't necessarily provide a tree script type architecture.

I'd be happy to collaborate on my fork if you would like to expand this further, again I just would like to not directly mimic how another client does things to avoid dealing with the backlash.

[gmason0]

@slest1 + @Krulvis - i am not saying that DB invented TaskScript or Tree-Leaf architecture. If you look at @Frozen-tuna's existing implementation of TaskScript it is a near direct copy of DB's implementation of TaskScript. That is what I am trying to avoid so I had devised something that is called a StepManager.

I also don't like a few design choices I mentioned above, like returning the sleep duration into the abstract loop or that it extends our current Script abstract class. I think it's something that should be completely independent of that & for a couple reasons

1. Our current Script architecture allows for multiple concurrent tasks to run. The step manager architecture mitigates this by using single threaded executors.
2. The Script class extends Global, which contains a lot of sleep methods & sleepUntil methods, this is just an unnecessary dependency as the sleeping would happen in each step , not the step manager.

This is why i had proposed this solution instead as it's not a direct copy of DreamBots implementation but rather something inspired by it.

[gmason0]

@Frozen-tuna - I think it's mostly working, i just want to take the time to finish the docs to better formalize the implementation & i would maybe want to create a couple more "AbstractStep"'s, not sure if you saw that on my fork, but i think it would be nice to create something like an abstract bank step similar to the abstract dialogue step so we could encapsulate those sort of common actions & pass a builder object that you could chain simple actions together

[slest1]

@g-mason0 Ah gotcha. Maybe i misunderstood, It was more so towards people labeling things as stealing so I was trying to clear the air. The step manager architecture mitigates this by using single threaded executors. I'm onboard with this. I think this avoids concurrency issues later down the road. Good addition George.

[Krulvis]

@g-mason0 I agree with the returning int to sleep not adding any real value. Although there could be some benefit to adding a small sleep in the Task executor to prevent it from going to crazy and causing memory issues.
As for the Step design you've promoted, it is fundamentally different and more complexity compared to the TaskScript presented by @Frozen-tuna . Both seem to serve a different purpose and I don't see a reason to take one over the other.

[gmason0]

@Krulvis - It still provides the same fundamental functionality that is desired

Create, small - focused classes that can serve a single purpose that can be registered to a manager to validate & queue tasks

As far as the abstraction itself, i think it can manage being complex as long as properly documented which is what i am working on wrapping up

[Krulvis]

Nice! I am a big fan of branch-leaf based scripts. I've build and implemented the TreeScript design for PowBot and can do the same for Microbot in the near future. For my personal taste the power truly lies in adding generic references to the Plugin/Script in each tree component so you always have direct access to the main class (Plugin/Script) with all its fields and methods made available to you.

[gmason0]

As he mentioned above, he doesn't feel this is needed/in-scope & primarily is looking for something similar to a Task/Step based script we could probably handle tree leaf after we finish polishing up the step manager I posted above.

I want to avoid being accused of mimicking other clients features as its bitten us in the past before.

[Frozen-tuna]

Agreed. I think tree-leaf is only required for some really advanced scripting like Gauntlet or Farming. Maybe that can be revisited after we get this first level of abstraction built in. Following the step-queue archticture, that's like setting up staircases haha.

[Krulvis]

I wasn't implying that it's necessary for his PR. Just sharing my personal experience and enjoyment from working with TreeScripts, showing that I am a fan of it.
The code I added to PowBot was something I wrote for TopBot like 10 years ago and is based on a very well-known straightforward Behavior-tree design. It cannot be claimed by any bot to be 'theirs'. It can probably enjoy some improvements through the collaborative community that exists here so it won't every be mimicking.

[Krulvis]

Agreed. I think tree-leaf is only required for some really advanced scripting like Gauntlet or Farming. Maybe that can be revisited after we get this first level of abstraction built in. Following the step-queue archticture, that's like setting up staircases haha.

I don't think you've fully read the Step architecture. It adds some complexity compared to your Task or a Behavior-tree systems. Since the validation of steps runs in different threads and steps are only enqueued after validation, it can cause some unexpected behavior that you need to be really careful with. Your Task, or any other single-threaded blocking design are simpler to debug and following the logic. In behaviour-trees, state-machines and task system tasks are sequential and based on order (very straightforward). While a system like the step-design is not and a high-priority step can block everything else constantly, disregarding order.
I am not saying the step-design is bad in anyway. I am just pointing out that it is not as straightforward or comparable to Task-design as you might think and will probably give a lot more headache to new users that are aiming for a simple and easy-to-read plugin.