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). 

I was thinking of something like this yesterday omg 'o.O was a nice read imo. with the goals - I was thinking with the same thing but instead of level goals like requirments for quests and all that jazz (BASICLY LEVEL GOALS WITH A REASON LOL). 

I love it. I too, agree, that we need to spend less time focusing on the actions of a single activity, and more on how the bot decides what it wants to do. I also love how you've broken it down into 2 strategies: Logical, Goal-oriented behavior - what i can do , and random Human-like behaviour - what it WANTS to do.

Sounds great - registered just to say that honestly.
Best of luck.

Great read, goal-oriented planning is a really powerful technique in AI development (You can see it in such games as F.E.A.R) and would work just as well in the botting sector. There are probably also more ways to further simplify the process, such as having generic InteractScript, initialized with a filter for the desired NPC e.g.

public InteractableSubscript extends SubScript<MyScript> {

     private String interactableName;
     private String interactOption;
     private Filter<Entity> entityFilter;

     public InteractableScript(String interactableNamem String interactOption, Filter<Entity> entityFilter){
          this.interactableName = interactableName;
          this.interactOption = interactOption ;
          this.entityFilter= entityFilter;
     }

     @Override
     public void process() {
          getScript().getWebWalker().interactWithClosest(interactableName, interactOption, entityFilter);
     }
}

This would theoretically work with my framework, and already that's half a Woodcutter/Fisher/Miner etc. Excuse me if I created the class incorrectly :x

Edited May 8, 201510 yr by Valkyr

Great read, goal-oriented planning is a really powerful technique in AI development (You can see it in such games as F.E.A.R) and would work just as well in the botting sector. There are probably also more ways to further simplify the process, such as having generic InteractScript, initialized with a filter for the desired NPC e.g.

public InteractableSubscript extends SubScript<MyScript> {

     private String interactableName;
     private String interactOption;
     private Filter<Entity> entityFilter;

     public InteractableScript(String interactableNamem String interactOption, Filter<Entity> entityFilter){
          this.interactableName = interactableName;
          this.interactOption = interactOption ;
          this.entityFilter= entityFilter;
     }

     @Override
     public void process() {
          getScript().getWebWalker().interactWithClosest(interactableName, interactOption, entityFilter);
     }
}

This would theoretically work with my framework, and already that's half a Woodcutter/Fisher/Miner etc. Excuse me if I created the class incorrectly :x

It's actually one of the first subjects tackled in the AI wiki ;)

 

You got the syntax correct And you're right, having a generic interact script would be extremely useful, although I'm not too fond of the lack of type safety with Strings. I would most likely make constants through enums.

 

If you're interested, I'm actually looking for developers to partner up with me on some (potentially profitable) botting related projects. I have a quiz to test your Java skill (but from the looks of the replies, it seems to be more of an introduction to a lot of things :P), which I'm using to find developers to work with. I don't expect anyone to answer EVERY question, but I do hope they do a little research before answering, and to give an explanation in their own words rather than ripping off the internet. You can find the quiz here. If you're interested, please send me the answers in a private message I understand you have your own scripting thing going on, so I would totally understand if you don't want to. Although I'm not expecting you to drop what you're doing to work with me, as long as you can still put in what you would be credited (and paid, if its a profitable project) for.