Few General Questions

[ScummyBotter]

Hey guys, got a few questions that are coming up as I'm making my first script:

1. If we make a script (the way I'm doing it now), we make instance methods to provide the functionality and stick them in onLoop (well, they're nested in each other but eventually they all stem from onloop), but what object are these instance methods linked to? Not our script right? since to make an object we need a constructor?

2. What "architectures" or methodologies are there when it comes to structuring a bot, I've heard of FSM or state based and something to do with task systems, is there anywhere I can learn about that?

3. I'm a bit lost when it comes to learning where my script fits into the whole program, what is the best way to learn this, just read the API docs and work my way down the tree?

[Alek]

20 minutes ago, rsplayerz said:

Hey guys, got a few questions that are coming up as I'm making my first script:

1. If we make a script (the way I'm doing it now), we make instance methods to provide the functionality and stick them in onLoop (well, they're nested in each other but eventually they all stem from onloop), but what object are these instance methods linked to? Not our script right? since to make an object we need a constructor?

2. What "architectures" or methodologies are there when it comes to structuring a bot, I've heard of FSM or state based and something to do with task systems, is there anywhere I can learn about that?

3. I'm a bit lost when it comes to learning where my script fits into the whole program, what is the best way to learn this, just read the API docs and work my way down the tree?

Sounds like you go to university by reading question 2. Remember that whatever "architecture" you develop, you're still running in the loop because that's how OSBot's script executor works. An FSM/automata is a little silly because of the formal name, but it means the same thing when we refer to a "state based" script. This involves the onLoop checking to see what state we are in:

 

onLoop() {
state = getState();
}

getState() {
if(a) return State.A;
if(b) return State.B;
}

Tasks are very similar:
 

onLoop() {
for(Task t: tasks) 
if(t.readyToExecute())
t.execute()
}

Both have their purposes, however they get abused a lot. Remember that the more you abstract, the more the computer has to work - especially in task systems where there is similar code shared between shouldExecute and execute methods.

For instance:

shouldExecute() {
npcs.getClosest("ABC") != null
}

execute() {
NPC npc = npcs.getClosest("ABC");
if(npc != null) 
npc.interact();
}

Here are some good starting places for you:

Also here's an IntelliJ setup. It sounds like your experienced, but I figured I'd share it with you anyways just in case:

 

 

[dreameo]

I think you should avoid all the state and task stuff.

Start out simple and if you don't like it, explore more appropriate designs.

if(canCut){
  cut();
}

lol, something like this would be in your onLoop... Think you get the idea

[ScummyBotter]

11 hours ago, Alek said:

Sounds like you go to university by reading question 2. Remember that whatever "architecture" you develop, you're still running in the loop because that's how OSBot's script executor works. An FSM/automata is a little silly because of the formal name, but it means the same thing when we refer to a "state based" script. This involves the onLoop checking to see what state we are in:

 

onLoop() {
state = getState();
}

getState() {
if(a) return State.A;
if(b) return State.B;
}

Tasks are very similar:
 

onLoop() {
for(Task t: tasks) 
if(t.readyToExecute())
t.execute()
}

Both have their purposes, however they get abused a lot. Remember that the more you abstract, the more the computer has to work - especially in task systems where there is similar code shared between shouldExecute and execute methods.

For instance:

shouldExecute() {
npcs.getClosest("ABC") != null
}

execute() {
NPC npc = npcs.getClosest("ABC");
if(npc != null) 
npc.interact();
}

Here are some good starting places for you:

Also here's an IntelliJ setup. It sounds like your experienced, but I figured I'd share it with you anyways just in case:

 

 

Yeah I'm currently at uni but the OOP we're taught just covers the fundamentals without that much practice, one of the reasons I came here is for that but it's been over a year since I played around with Java and OOP.

Thanks for explaining the state and task systems, you mentioned that the more you abstract the more the computer has to work, does the readability and clarity not help when it comes to that? Otherwise you'll have a bunch of lower level code which is a pain to visualise.

I used those resources when I started a few days ago, definitely useful, just to clarify though when I said that I wasn't sure where my script fit into the program, I meant into osbot as a whole. So any bot we write is a subclass of script which is a subclass of MethodProvider etc, is the best way to learn this to simply read through the docs?

Somewhat related to that was my first question, from my understanding of java and OOP, instance methods are methods linked to an object which can be instantiated, and all objects need a constructor method to be instantiated but our scripts don't have constructors yet still have instance methods, so what objects are the instance methods linked to, the superclasses? is that a thing?

I realise I'm asking a lot of questions so these are open to everyone not specifically just you

9 hours ago, dreameo said:

I think you should avoid all the state and task stuff.

Start out simple and if you don't like it, explore more appropriate designs.

if(canCut){
  cut();
}

lol, something like this would be in your onLoop... Think you get the idea

That's what I'm doing now, only problem is that I'm like 3/4 of the way through my script and have 350 lines of code in one file, even though I'd like to think it's fairly clear to read, there's still too much in one file for my liking and I'd like to know how to split it up

 

[dreameo]

6 hours ago, rsplayerz said:

That's what I'm doing now, only problem is that I'm like 3/4 of the way through my script and have 350 lines of code in one file, even though I'd like to think it's fairly clear to read, there's still too much in one file for my liking and I'd like to know how to split it up

The only issue with trying to do OOP is that, you have to maintain a single reference across multiple classes.