From what I've seen so far with bot scripting, it seems a state machine would be perfect for bots. Something where scripters can create "states" for each action they want their bot to do (walk to bank, walk to next tree, ect..), add those states into a machine, then process each action individually, as if each state class had it's own "onLoop" method.

 

I'm not familiar with the onLoop method (such as why it returns an int), but it seems like an easy way to allow scripters to focus on one action at a time while creating their bot, without having to sift through a bunch of conditions in the onLoop method.

 

I've seen other attempts at creating some kind of self-managing script, but I feel my attempt is a lot more elegant, as well as efficient. Something like this could be implemented into the API, similar to how you have a SmartScript. This is just a concept; haven't tested myself, but can be worked on. The idea still remains: register states, allow the current state to do what it needs to do, switch to another state afterwards, and let the cycle continue. The states are mapped, so access to the next state will always be O(1). Keep in mind that the executions can be managed in a more secure way (such as setting a constructor to be accessible if client decides to declare constructor private on an IllegalAccessException):

 

Client's View

Their bot:

public class Bot extends StateScript {

     @Override
     protected void registerStates(StateMachine manager) throws InstantiationException, IllegalAccessException {
          manager.add(BankState.class);
          manager.add(MakeOakPlankState.class);
          manager.add(WalkToMillState.class);
          manager.add(WalkToBankState.class);
     }
}

BankState (just for an example of a state):

public class BankState extends State {

     @Override
     public void process(Script script, StateMachine manager) {
          //handle banking using script; script.inventory.contains(...)

          manager.switchStateTo(WalkToMillState.class); //to switch to next state
     }
}

The process methods could return an int, which onLoop returns; although like I said, I have no clue what it's for, so please don't down me for not accounting for it.

 

You could store the class literal (for when you switch to the next state) in a field variable, although that's micro-optimization. This also does not account for multi-threaded scripts, but thread-safety can easily be implemented.

 

API View (just a rough draft, could be improved upon request)

This is the part scripters don't see; embedded in the API

StateScript

public abstract class StateScript extends Script {
     private StateMachine manager;

     @Override
     public final void onStart() throws InterruptedException {
          super.onStart(); //not sure if this is needed

          manager = new StateMachine();

          try {
               registerStates(manager);
          } catch (Exception e) {
               e.printStackTrace();
          }
     }

     @Override
     public final int onLoop() throws InterruptedException {
          manager.process(this);
          return 0; //fit this into the mix somehow; I'm not sure what it's for
     }

     protected abstract void registerStates(StateMachine manager) throws Exception;
}

StateMachine

public class StateMachine {
     private HashMap<Class<? extends State>, State> states = new HashMap<>();
     private State currentState;

     public void add(Class<? extends State> state) throws InstantiationException, IllegalAccessException {
          if(states.get(state) == null) {
               State newState = state.newInstance();
               states.put(state, newState);

               if(currentState == null)
                    currentState = newState;
          }
     }

     public void switchStateTo(Class<? extends State> state) {
          State nextState = states.get(state);

          if(nextState == null) {
               //terminate or create some kind of error state or allow client to choose "default" state
          }

          currentState = nextState;
     }

     public void process(Script script) {
          currentState.process(script, this);
     }
}

State

public abstract class State {
     public abstract void process(Script script, StateMachine manager);
}

Not much to it. After seeing the "Node" design that people were using, I thought this might be a useful feature in the API

 

 

Edited January 24, 201511 yr by fixthissite

I'm not sure what benefit this has over simple task execution? Seems like an overly complex for loop. Simply creating a #provide method in the StateScript, which can be called from the implementing script itself, should just store the provided states in a list for iteration. There's no need for dynamic class invocations.

 

FYI the thread will sleep after each #onLoop iteration by whatever was returned from the #onLoop.

I'm not sure what benefit this has over simple task execution? Seems like an overly complex for loop. Simply creating a #provide method in the StateScript, which can be called from the implementing script itself, should just store the provided states in a list for iteration. There's no need for dynamic class invocations.

FYI the thread will sleep after each #onLoop iteration by whatever was returned from the #onLoop.

As I've mentioned, this uses a mapping system allowing for O(1) access to the next state (as appose to iterating through a list to see if a node is "visible" like the current popular "single stage node framework", which is O(n)). This "overly complicated for loop" is called a state machine, and this is the correct logic for situations like this. It's not overly complicated at all, this is actually extremely simple, and it's a lot better than managing a script that's crammed inside the onLoop method.

This would be the correct way to handle a bot (a deterministic finite automaton might be more efficient, but I didn't wanna overwhelm people with a transitionctable). I highly suggest looking into automatons. Google gives a real nice definition which strongly relates to this subject: a moving mechanical device made in imitation of a human being.

Although this isn't a full fletched automaton, due to the lack of a transition table, it still carries the same idea.

And thanks for the info about the loop. That's what I figured at first, but I would personally think the wait time would be somewhat random, which doesn't seem to be the case in most scripts I've seen, making me believe there was more to it. Like I said, I'm still trying to wrap my mind around how this entire bot thing works, so I can't be 100% sure something like this would be possible with the current structure; I'm going based off what I find to be logical for a bot: specifying states, managing those states in isolation (to keep code clean), having each state specify where it should go next (the next stsge depends on hoe the current state processes), then letting it run on it's own

Edited January 14, 201511 yr by fixthissite

My latest script actually implements something very similar.

My latest script actually implements something very similar.

Yes, tell us more about how your latest script uses this.

 

Coming from the person who just made a topic complaining about how they have to have 100 post count to sell accounts, I'm almost positive you have 0 clue about how to script and this is just for the post count. If not prove me wrong and let's here more about how you implemented this into one of your scripts. 

Yes, tell us more about how your latest script uses this.

 

Coming from the person who just made a topic complaining about how they have to have 100 post count to sell accounts, I'm almost positive you have 0 clue about how to script and this is just for the post count. If not prove me wrong and let's here more about how you implemented this into one of your scripts. 

 

I've been a Java programmer for a few years, as well as a Web Designer.

Additionally, I've got a bit of experience with server configurations.

 

 

Current project tree for my AIO Game Progression Script:

 

Example code for the Task Manager:

 

Part of my Node class:

 

Uses simple reflection to load a class instance and process it for each iteration where certain conditions are met.

Pretty cheaphax, but it works for now.

Edited February 8, 201510 yr by CallMeDominic

Sorry, but this is not a project I'm willing to embark on in the foreseeable future.