Dreamlicker

What type of user are you? (Scripter, casual user, heavy user) Casual How many bots do you usually run at one time? 1 How long have you used DreamBot? Long time Going to make a library might as well do it for 3

You can get DB3's here any time. https://www.mouser.com/ProductDetail/STMicroelectronics/DB3?qs=%2BX2uje6VeKWa17pCEVBPdA%3D%3D

You need to associate .jar files with Java. I'm sure there are some good tutorials on how to do that if you google it.

ya dont use tabs

There is a reason not to, it's that the point of the class is to access the method context of the script from any class without having to pass around the context. That is explicitly what OP wanted as far as I can tell. Utilizing methods within the main script from within the accessor is bad design, and not only because the purpose of the accessor is not to use the main script class. You don't create separate method contexts. You use the accessor to operate on/with the context from within other classes that have their own responsibilities (single responsibility principle). The fact that it's a singleton means nothing in regard to the api/script/whatever. The only point of a singleton is to provide a global access point to an object that is guaranteed to only have a single instance, preventing duplication of objects it contains. The example I posted is slightly weak as we're trying to ensure that the class receives a dependency through the initialize method, but if you ensure that you only ever call the initialize method from onStart, you can avoid that pitfall. Better yet, utilizing a class that inherits from AbstractScript or TaskScript and calling initialize in onStart within that class (and extending from it to create your main script class) will ensure you avoid any issues. A well designed system does not put every piece of functionality into a single place, avoiding an anti-pattern (the blob). It's important to promote separation of concerns in your design, which the accessor facilitates. However, I think it's a little silly to not just pass the context in the constructor as you're going to be instantiating it somewhere anyways. You could use a factory to handle the dependency injection if you really wanted. In general, none of this is really reasonable unless you're making a large script. If OP is, then i'd design it like I would any other program. If not, sticking most everything in the script class/nodes is not that big of a deal.

You cant make that generic. If you think you can, post code that compiles. I'll give you $5. Why would you pass the main script? It does not make it any clearer.

you could make a singleton accessor for the context like public class Accessor { private Accessor instance; private MethodContext context; private Accessor() {} public static void Initialize(MethodContext context) { instance = new Accessor(); instance.context = context; } public static Accessor GetInstance() { return instance; } public MethodContext getContext() { return context; } } public class mainscript extends etc { public void onStart() { Accessor.Initialize(getContextWithWhateverMethodItIs); } } public class otherdude { private MethodContext context; public otherdude() { context = Accessor.getInstance().getContext(); } public void eat() { context.GetInventory().get(i -> i.getName().equals("Tuna")).interact("Eat"); } }