Passing Context to Classes

[sintaax 0]

I have read examples from the guy whose name is hashed where he passes the main class file to other classes in order to still be able to call the same contextual methods.

I must say that is a horrible practice and impossible to do for classes that exist outside of the default package.

With PowerBot, there is a contextual object that can be created to pass the context on to other classes like so:

package engine.objects;

import org.powerbot.script.ClientAccessor;
import org.powerbot.script.ClientContext;

public abstract class Context<C extends ClientContext> extends ClientAccessor<C> {
    public Context(C ctx) {
        super(ctx);
    }
}

The only problem is that I have not discovered how to replicate this for DreamBot.

How can I pass the ClientContext (MethodContext?) on to other classes without invoking the NullRefException or... passing the main class (which is an absolutely god awful idea)

[dQw4w9WgXcQ 184]

 

Theres a method https://dreambot.org/javadocs/org/dreambot/api/methods/MethodContext.html#registerContext-org.dreambot.api.Client- to pass the context to another class, however this creates separate api classes (each instance of methodcontext will have separate Bank,Inventory, Equipment, etc.) You should only use it if you are trying to avoid concurrent mod exceptions.  Passing the entire script also gives you access to all the methods from AbstractScript (stop() etc).  

44 minutes ago, sintaax said:

I must say that is a horrible practice and impossible to do for classes that exist outside of the default package.

protected variables are available to subclasses as well, if you need them public it should be done using a getter.

[sintaax 0]

I'm definitely not looking to instantiate multiple instances of MethodContext. Just looking to make use of the one instance of the client context.

Looking through the flow, I see that the AbstractScript is extended from MethodContext which is extended from MethodProvider which contains a field that contains a Client which is constructed using Instance which is inaccessible to regular users.

Having a way to pass a singular instance of the context through constructors would enable cool things like this:

public class Manager extends Context<ClientContext> {
    public Manager(ClientContext ctx) {
        super(ctx);
    }

    public static int activeQuest;

    public static TaskHandler th = new TaskHandler();
    private VarpbitSpy vbs = new VarpbitSpy(ctx);

    public void execute() {
        vbs.pollChanges();
        refresh();
    }

    private void refresh() {
        updateTasks(Arrays.asList(new Controller(ctx)));
    }

    public static void updateTasks(List<Task> tasks) {
        th.reset();
        th.tasks.addAll(tasks);
        th.execute();
    }
  }

public class Controller extends Task<ClientContext> {
    public Controller(ClientContext ctx) {
        super(ctx);
    }

    @Override
    public boolean activate() {
        return new ZeroController(ctx).activate() || new CooksAssistantController(ctx).activate();
    }

    @Override
    public void execute() {
        Manager.updateTasks(Arrays.asList(new ZeroController(ctx), new CooksAssistantController(ctx)));
    }
}

 

[dQw4w9WgXcQ 184]

clientcontext can just be replaced with the main script in your examples above, just make it public final or use a getter. 

There's nothing wrong with passing the main script.  if you want you can wrap it in a Context<M extends RickkScript> and make Node extend Context, but for the sake of simplicity i didn't in the tutorial.  

[sintaax 0]

we might be going in circles but that pattern disallows the creation of additional packages as the default package which contains the main class is not referenceable (except maybe through reflection?) .

passing the main class forces the whole package to be mighty reminiscent of a C++ repo where all of the source and header files chill together in an entirely unstructured clutter

I’ll mess around with your suggestion to see what I can make of it

[dQw4w9WgXcQ 184]

1 hour ago, sintaax said:

we might be going in circles but that pattern disallows the creation of additional packages as the default package which contains the main class is not referenceable (except maybe through reflection?) .

passing the main class forces the whole package to be mighty reminiscent of a C++ repo where all of the source and header files chill together in an entirely unstructured clutter

I’ll mess around with your suggestion to see what I can make of it

you can use generics the same way as u used them above.  

 

to elaborate, you would have a module that holds your api required by your other modules (individual scripts).  The api module contains Context<M extends RickkScript> and RickkScript.  In some module, SomeScript extends RickkScript and SomeClass extends Context<SomeScript>.  its no different what you did above, theres no reason not to pass the script.  

[sintaax 0]

except for the inaccessibility of the default package...

even reflection has proven to be ineffective.

oh well, time to bite the bullet and move on from the default package and into named packages.

maybe once I learn Java IoC I can revisit this

[dQw4w9WgXcQ 184]

i thought you were just confusing modules and packages but you were actually using the default package.  😃🔫

[dQw4w9WgXcQ 184]

"I must say that is a horrible practice"

[Manly 879]

You can get the methodcontext statically through the client class, but I'm not sure how this will work. I've done it when I've been lazy af.