The opinion/theory below is going based off what I'm seeing. Please correct me if I'm wrong. If you write a skilling script, there's a very limited amount of things you can do to make your script unique compared to other scripts of the same type. There's really not too much to a script, and honestly, there doesn't seem to be much diversity between bots doing the same skill (pretty simple minded). Please criticize anything I've just said; I'm not TOO familiar with scripting yet. Skilling scripts as they are now can easily be perfected, and there's not much reason to create a script after perfection (all the functionality needed to achieve botting for that skill). There's only so many skills you can cover, and with things like the Node framework, making a script is pretty damn easy. Scripts are too single-minded (in my opinion). They focus on one thing (skill, quest, activity), which people then question why they can't bot for hours on end. Being an ex-runescaper, I know people can play for days at a time without getting banned (from what I remember, the most I've played was 78 hours, legit playing). There's not much room for anti-ban, and it seems people are only focusing on random timing and path traversing for anti-ban techniques. What do you think of having a library of skilling scripts to choose from (or creating your own), "binding" those to your main script, then allow your main script to handle transitions between activities (where you can implement anti-ban techniques, such as unlocking music tracks if you're near an area that has a track you haven't unlocked yet; human-like actions similar to that).
EScript
A script today would represent a subscript in this, and you could easily create and distribute subscripts (if you feel current subscripts arent to perfection). The syntax would look like:
@SubscriptBind(subscripts = {
FiremakingScript.class,
WoodcuttingScript.class
})
public final class MyScript extends EScript {
//handle human-like logic; explained later
}
Your subscript would look like:
public final class FiremakingScript extends Subscript<MyScript> {
//can use getScript() to access script; recommended to store in field
public void process() {
//similar to onLoop; framework handles random timing
}
}
Developers could program at 2 different tiers: cognition (human-like logic) and abilities (subscripts). They can implement what they feel a human-like bot would do (some may think unlocking music tracks is a stupid anti-ban technique. I actually used to always love unlocking tracks ), and create diverse scripts by using different combinations of subscripts. You might be wondering about the paint. It's an optional feature. Each subscript has it's own paint (I have yet to create a master paint system), which you can create by subclassing a Paint abstraction, then bind to the subscript:
@PaintBind(paint = FiremakingPaint.class)
public final class FiremakingScript extends Subscript<MyScript> {
//...
}
public final class FiremakingPaint extends Paint<FiremakingScript> {
//getModel() to access script details to be rendered
public void render(Graphics2D g) {
}
}
The paint acts as the view, the subscript acts as the model, and the script acts as the controller, so technically this is the Model View Controller pattern if you were interested in knowing. This allows you to keep your code clean, and allows subscripts to be isolated and redistributable. The idea of this API is to take developer's focus away from developing what has already been done (with a few minor added features) which lacks anti-ban support, and directs their focus towards developing different types of "personality" for bots. I have also been working on a Goal system, to simplify the cognition system. The idea is to write Goals for a certain Script (not subscript) which performs switching between subscripts as needed to achieve the goal. Goals will be executed linearly unless you specify your own GoalManager. A custom GoalManager allows you to switch between subscripts mid way, storing an image of the current node's state before switching. This will be the heart of the cognition system, and is currently under construction. Right now, cognition is handled by simple conditional branching, allowing the developer to implement whatever logic he feels would prevent bans (woodcut for 50 minutes or until you get a certain amount of logs, then firemake. while walking, look for music tracks you haven't unlocked yet and see if you're near any locations). The uniqueness of the bot comes from the creativity of the developer.
Keep in mind that you don't want your logic to be repetitive. There are many techniques to ensure your bot doesn't perform the same pattern of actions continuously.
I am adding an AntibanBind, similar to the SubscriptBind, allowing you to encapsulate AntiBan techniques (such as scanning the chatbox for things that could influence the bot into doing something else). AntiBan instances are independent of your script, and should provide functionality. It doesn't decide when the anti-ban actions are performed; it should know nothing about your script or subscripts that can't be accessed through org.osbot.rs07.script.Script. It's primary goal is to provide your bot's cognition with tools that allow it to perform actions a bot typically wouldn't do. Lots of philosophy to be uncovered there.
The main difference between a subscript and an antiban is the responsibility: subscripts process logic, antibans provide logic to be processed.
Please, don't go easy on me. If you see something you personally don't find attractive, let me know in detail. I strive for constructive criticism, so let me know what you REALLY think
If feedback suggests an alpha model should be released, it will be done so tonight (excludes the Goal system, but might include the AntiBan system).