FrostBug

Just a guess, but it may be that Objects#getAll iterates the coordinates of the region graph, adding all InteractableObjects found. If this is the case, the result might be that an object of 2x2 size (large object that spans 4 tiles) would be added multiple times, as it can be found on multiple coordinates, even though the objects 'anchor position' is the same. Depending on whether or not they're the same object instance, using Collectors.toSet might function as a workaround

You're walking regardless of whether or not you have a Pot, but only write to logger if you don't have a pot.. I have a hard time understanding the logic behind this; but okay. The conditional sleep waits from the moment you've finished walking, up to 4 minutes.. Why? Nothing is gonna change once it's finished walking. This is not an async event.

You running mirror mode? Make sure to choose injection; try restarting client for the null thing; last time I heard of that happening, it was fixable with a client restart, or by opening equipment tab before starting.. something with the client failing to read equipment for some reason EDIT: also if you could PM me the log files (found in OSBot data directory) for those runs, that would be great (assuming it wasn't caused by running mirror mode)

I personally use injection (which is what I assume you meant)

Hi, Since you're a VIP user, there is no account limit.

Same problem was resolved here (Interact with mousedestination)

It won't do that if the area is on the screen with AreaDestination; this ignores widgets and whatnot Maybe try MouseDestination dest = new RectangleDestination(getBot(), InventoryMouseDestination.getSlot(slot));

Is the slot -1 or wot?

Well, I don't think you can do it with the built in API since it will close any open widget except for the bank one (which I believe is a hardcoded exception). Why do you want to do this anyway? It's a little ugly, but you could use this as a possible workaround: int slot = getInventory().getSlot(filter); MouseDestination dest = new AreaDestination(getBot(), getInventory().getMouseDestination(slot).getArea()); getMouse().click(dest); The extra MouseDestination wrap is because I believe the widget check is actually located in the InventoryMouseDestination class; at least it used to be, might've been changed since. EDIT: If it has been changed, you can remove the AreaDestination wrap.

Well, if you could provide screenshot/gifs of these scenarios getting stuck, that would help. I never make script changes based on speculation; not with this one. I still do test runs occasionally, but haven't had any issues the last few times. I'll do some more soon to make sure. For minimap interactions and such, that can often be caused by settings such as screen zoom or resizable mode; so ensure that those are at default and fixed (probably is; but make sure anyway). Most of the script changes at this point are very technical; most often minor changes to the evaluation heuristics (the numbers used to make decisions); I don't think it'll make much sense to specify these in the OP. I'll have a look. Was this using 'Quick-start', or did you manually specify numbers of potions? If so, how many of each did you specify? Also is there a difference between these images? What am I looking at here

Sure, let me know when.

Damn, you almost had it

No - most scripters use a web server as a mediator between script and database

That is not the full error, but we'll work with it you can use the Tabs api to switch tabs

In the future, including the error may be helpful. Probably the widget 'chatbox' is null in this case, though. In other words a widget with those IDs was not loaded or visible at the time.

I'll try to remember adding the trial tomorrow Gud-guy @evenflyox answered the rest

Change break settings?

Well it won't do that with 90s or 360s as they are just as likely to attack with range/mage even in melee distance

Like Bronze said, it should include melee in the prayer flicking if jad is in a position to melee attack. @Bronze do you mean that if jad can't settle under the player, it wont pray melee? That sounds odd, but I'll def have a look into it

Yes, but it won't recharge it

The login handler seems to pause the ScriptExecutor. This would conflict with the fact that it's also a ResponseCode listener, as the ResponseCode listeners (I believe) are invoked between calls to onLoop (which will not happen when ScriptExecutor is paused). Perhaps it's outdated.

Maybe didn't execute the event properly

Right there on my profile. live:frostbug_1

Just making an InteractionEvent around a MouseDestination rather than an Entity will probably get your desired result, since it can't verify reachability.

Afraid not I can take a look over skype later today if you want. Tho from previous description it sounds like high ping or connectivity issues is the cause.