Simple tips I've learned while scripting: Avoid problems

[BigCahunaBurger]

Here's a list of things I've learned to do. I don't fully understand why you should do them, only that life is easier if you do:

 

1. Don't use any loops (for, while, etc) - all looping should be in the main osbot loop in the main class

2. Use if/then, not case statements
3. Keep all conditions in the main loop

4. If your use-case is RAM and CPU sensitive, use path walk, not webwalk

5. Do not use recursion. Java is not designed for recursion. If you must use recursion clojure should work in theory

6. The beginning of any action should be evaluated and started from the main osbot loop

7. One script for one task, use a manager for multiple tasks

 

Edited January 6, 2022 by BigCahunaBurger

[PyNN]

I'm not really sure some of these things are correct not gonna lie.

 

Quote

1. Don't use any loops (for, while, etc) - all looping should be in the main osbot loop in the main class

Maybe behavior related loops should be here, and for search related loops you could use filters/find to help eliminate looping, but I've never ran into any problems using loops in scripts. Not sure this is the best rule to have since they can definitely find their places in scripts and work

 

Quote

2. Use if/then, not case statements

Switch/case are generally more efficient that if/then, they do have their place and you should know when to use them and not to overuse them.

1 hour ago, BigCahunaBurger said:

7. One script for one task, use a manager for multiple tasks

Probably good for beginner scripters (depending on how you're defining a task), but it's definitely possible to write multipurpose scripts fairly easily once you become more experienced.

 

Maybe some other people can share their thoughts too though, this is just my perspective.

[BigCahunaBurger]

43 minutes ago, PyNN said:

I'm not really sure some of these things are correct not gonna lie.

 

 

Thanks for your perspective. I guess from my POV I'm trying to make scripts that have very small footprints and easy to handle / easy to debug memory behavior. The goal of my scripts is to be able to run as close to a hundred of them as possible on a given piece of hardware. Of course you can make good scripts that execute a variety of functions and especially I imagine for people who want to level their account or are consuming the scripts as sort of like end users this makes a lot more sense than fragmented tiny scripts that require a manager. Feel free to correct me if I'm wrong about something

You're right about case switches from a fundamentals perspective (how the compiler interprets them) but for some reason I just can't get them to behave the way I want in osbot. Explv seems to use case switches with getConfigs which makes a lot of sense but doesn't seem to work for my use case (maybe I'm just not thinking of the algorithms in the right way)

I ran into a number of problems with while loops, similar to this and some other threads. I appreciate your distinction between behavior related loops and search related loops, since it seems behavior related loops are the main problem

 

[Khaleesi]

One of the biggest tips I can give is to limit the amount of things you do in a loop to 1. Do 1 interaction and let the loop finish and the next loop check what the next things is to do
Don't chain multiple interactions in a row.

For example for withdrawing something from the bank.

BAD

onLoop(){
    openbank();
    depositInventory()
    withdrawItem();
    closeBank()
}

 

GOOD

onLoop(){
	if(bank.isOpen()){
		if(inventory.isEmpty()){
			withdrawitem();
		}else{
			depositInventory();
		}
	}else{
		openBank();  
	}
}

1. Don't use any loops (for, while, etc) - all looping should be in the main osbot loop in the main class
Loops are powerfull, I use them all the time and you will need them. You just need to know when to break a loop.
Just don't use loops to execute anything, because that will cause issues.

2. Use if/then, not case statements
I usually prefer to put them in an enum and loop over the enum instead of using a switch

3. Keep all conditions in the main loop
Not sure what you mean by this, but you should only be using the onLoop to execute code that interacts with the game.

4. If your use-case is RAM and CPU sensitive, use path walk, not webwalk
True, but only if it's possible. If you have a clue scroll solver, you don't want to make 5000 paths ^^

5. Do not use recursion. Java is not designed for recursion. If you must use recursion clojure should work in theory
Ya fuck that. in most of the cases recursion isn't very readable anyway.
I don't see a point in using that ^^

6. The beginning of any action should be evaluated and started from the main osbot loop
You should only use the onLoop to execute code that interacts with the game and always use an IF to check if it was executed.

Edited January 6, 2022 by Khaleesi

[Gunman]

Fucking loops go bbbrrrrrrrrrrrrrrrrrrrrrrrrr bro

[BigCahunaBurger]

Thanks Khaleesi, I appreciate this information. I'll setup my onLoop as you described

A few questions

1. Are there any posts I read or info on when to break the loop? I generally understand it should be broken when it has finished its function

30 minutes ago, Khaleesi said:

2. Use if/then, not case statements
I usually prefer to put them in an enum and loop over the enum instead of using a switch

2. Would you mind giving an example of what you mean here?

[FuryShark]

2 hours ago, Khaleesi said:

BAD

onLoop(){
    openbank();
    depositInventory()
    withdrawItem();
    closeBank()
}

 getBank().open();
 getBank().depositAll("Logs");
 getBank().close();

You called it 

[Khaleesi]

5 hours ago, BigCahunaBurger said:

Thanks Khaleesi, I appreciate this information. I'll setup my onLoop as you described

A few questions

1. Are there any posts I read or info on when to break the loop? I generally understand it should be broken when it has finished its function

2. Would you mind giving an example of what you mean here?

Well if you use a switch there is usually a better way to do it or cleaner way to do it.
Let's say you have some location where you want to chop trees, and they have ID 1 to 3.

You can either have a Switch where you set the values based on the ID you picked.
Or you put those 3 in a enum and all values in the enum, which makes it a lot more clean ^^

If you give me an exmaple of a switch case, I will tell you how I would implement it

[BigCahunaBurger]

1 hour ago, Khaleesi said:

Well if you use a switch there is usually a better way to do it or cleaner way to do it.
Let's say you have some location where you want to chop trees, and they have ID 1 to 3.

You can either have a Switch where you set the values based on the ID you picked.
Or you put those 3 in a enum and all values in the enum, which makes it a lot more clean ^^

If you give me an exmaple of a switch case, I will tell you how I would implement it

Let me take you up on this in a few days to a week. My brain is sort of tired today, lol. For rn I'm just refactoring this kind of convoluted AIO multi-task script into several scripts using very simple if/then logic on the main onLoop with only one interaction per loop, after I'm done I'll refactor it (if possible) into what you're talking about

[ProjectPact]

Loops aren't bad if you use them correctly. Also, take advantage of streams where allowed.

[BigCahunaBurger]

1 hour ago, ProjectPact said:

Loops aren't bad if you use them correctly. Also, take advantage of streams where allowed.

Thanks for mentioning this Pact, another thing I need to learn.

What I'm getting from this thread is a distinction I hadn't made between using loops and using case switches for variables such as arrays, item names, etc and actually interacting with the game world. I was just viewing it as all the same stuff. Makes more sense when you distinguish between interacting (which should avoid loops) and sorting/assigning/enumerating the variables of interactions which can and should use loops (is what I'm getting?)

Edited January 7, 2022 by BigCahunaBurger