Butters

Yeah, figured why not to share as there's none working on SDN atm (I think).

Yes, groundbreaking

On a side note, you need gmail specifically or will other email providers do? Cause if so, there's plenty of free ones.

Added request for SDN upload

You could just use the file system for this. Bots save files saying that they are ready to mule, mule "listens" for the files and logs in when needed (info provided in file). Would need custom login handler though. Btw seems like you did a good job on this, grats!

Imagine this scenario: Current OSBot file: OSBot 2.4.153.jar All fine and dandy and then a OSBot update hits. New file name OSBot 2.4.154.jar Automatic updates hit - they download the latest file. Now your launcher probably has a setting which tells it which OSBot file to use, how will you know which one to use? If auto updates won't change the file name to a previous one, no bueno for you. I seriously doubt this that the devs would implement something like this. Best bet would be to do it yourself: Check OSBot version - update needed - download latest file - rename

are cpu and ram issues out of the question?

In this case true But might help when the conditions are more complex. Of course can just write separate condition checking methods like private boolean needsBank() { //... } Btw good luck with the script and happy coding

This is not antiban, this is: 1) Moving mouse around 2) Moving camera around 3) Opening tabs To my mind, best antiban is in botting behaviour, like taking breaks and what not. A good read:

Aaah, then do if (dialogues.inDialogue()) { dialogues.clickCOntinue(); }

Not sure what you're on about. What's a level up window? One way to check if you have leveled up is grab the message from chatbox. Something like: @Override public void onMessage(Message msg) { String message = msg.getMessage(); if (message.contains("just advanced")) { log("Got level up message: " + message); } }

What's a webwalker loading screen? Can you provide screenshots or logs?

I really doubt that if they added a new button, they would change previous widget id's just to make "positioning" cleaner. Probably would end up as (just move the widgets around): 123, 1 - pos x = 1 123, 2 - pos = 2 123, 3 - pos = 4 123, 4 - pos = 3 Just thinking out loudly though.

Widgets contain max 3 ids: * Root * Child * Subchild (? or how do you call it). The requirement states that you can't use any lower id's than root id's. Meaning if you want to use a widget in your script, which's id's are 351 2, you SHOULDN'T do: widgets.get(351, 2); SHOULD do: widgets.getWidgetContainingText(351, "Some text that is in the widget"); The reasoning behind this requirement, to my mind, is questionable, but still has it's points: If you hard code the id's in your script, there's a chance that the id's will change after an update and your script will break. Though, in my mind, if Jagex changes any "child widget elements", I think they'll change the whole widget, meaning my previous example will fail as well. If you search for widgets only using text, there's still a chance that your script will function even after changing the widget.

Status: On SDN Intro: Had this script for a while and decided why not to share with you guys. Features: * Multiple locations: Varrock and Falador * Multiple containers: Supports Buckets and Jugs * Command line support: Can run directly from command line without GUI. See below for instructions. * Script will stop if you run out of clay or don't have 28 containers. * No Web Walking (uses little resources)/ Requirements:/usage * Have clay in bank (or noted in inventory). * Have 28 buckets or 28 jugs in bank or in inventory (noted works). * MUST START NEAR BANK OR WATER SOURCE. If you start the script too far away from bank or water source it will just stand still. CLI usage * Script ID: 1005 * Script parameters: Location. Atm only Falador and Varrock * Usage: java -jar osbot.jar -login yourOsbotName:yourOsbotPassword -bot rsAccountName:AccountPassword:0000 - script 1005:Falador GUI: Proggies: Changelog:

Approx what issue was it? Just curious if will solve the issue that I was having

Thanks for the reply. But this was the actual problem where getAll() didn't find the predefined objects, though they were quire close.

73 Tiles? Quite a lot. I test by completely relaunching the client, so should be fresh cache. Anyway, "solved" the issue by first traveling around the area for all objects to load properly. All works as expected after this.

Try to stand further away from your object until it's not visible in minimap and tell me how it goes What I noticed though: 1) Object must be on minimap to be found (after login). If it was on minimap earlier, then it can be found later without problems. 2) Methods closest(Area, objectName), getAll() adhere to the 1st rule.

This minimap thing might be the case. Will test to confirm. Though if it's true, any methods to load beyond minimap?

The original question was about general application. You can "know" the route by checking configs. Each pulled lever changes a config value so you can hardcode the path you want depending on the value. General idea was to make it universal regarding other areas that might need similar functionality.

Running this every loop iteration. Will try to see the size of the returned list, thanks! Thanks for the info. But isn't there something like a "loaded region"? Should be bigger than 15 tiles Also when I see the object in the distance I can right click on it and interact with it, so it's loaded in game, but the script has trouble finding it

What difference should it bring in just "finding an object that I can see". Atm I don't care if the object I want in the area I want, could be X other objects outside my desired area The problem I'm facing is that the script doesn't find the object even when I see it (from far away - maybe like 15-20 or so tiles). After playing around noticed that if I rotate the camera a lil towards the object, the script finds the object. Apart from adding failsafes like rotate camera or walk around, any bulletproof ways to do this?

This should "slim down" the possible results, not expand the search area