If you're new to Java, then I suggest you start with the basics. You don't need states and tasks to write a good script.

13 hours ago, progamerz said:

There is no other way lol

You have access to the bot context.

 

14 hours ago, dreameo said:

When you're extending MethodProvider, some inherited fields must be initialized. That is the only reason why you're getting null. 

What those fields are, i'm not sure (take a look in Script class and see how it handles it). There are different ways on dealing this situation. @Alek Can tell you the preferred way. I think he mentioned it before in the forums. 

By design scripters shouldn't use anything that's marked for internal use only. They should pass bot which derives everything for that instance. I don't even extend MethodProvider in our API, it just doesn't make sense from a design perspective - we pass MethodProvider or Bot. I'd encourage other scripters to do the same, but it's your code so do whatever you guys like!   
 

45 minutes ago, Alek said:

By design scripters shouldn't use anything that's marked for internal use only. They should pass bot which derives everything for that instance. I don't even extend MethodProvider in our API, it just doesn't make sense from a design perspective - we pass MethodProvider or Bot. I'd encourage other scripters to do the same, but it's your code so do whatever you guys like!   
 

 

Aye, passing MethodProvider or Bot as a parameter is certainly "better", I just hate having every API call prefixed with some variable like methods.myPlayer() or whatever, and every class having MethodProvider as a constructor parameter. It just makes me feel a little sad when I look at it

If I was writing a small script for sure I would just pass the context as a parameter, but for large scripts it starts getting ugly.

I guess an alternative would be to have a static MethodProvider variable in your main class, and access the API via that, but again... *shudder* not gucci

Edited December 21, 20178 yr by Explv