FrostBug

Can't do it with the Camera class

By exchanging contexts I mean: CustomBreakManager customManager = new CustomBreakManager(getBot()); customManager.exchangeContext(getBot()); getBot().getRandomExecutor().overrideOSBotRandom(customManager); Remember that you should still only override it if they have breaks enabled; otherwise it will throw an error as well. EDIT: exchanging contexts is something you must do when creating new instances of classes that inherit from MethodProvider, and BreakManager does inherit from that. This also means that there is no need to store the reference to Bot in your custom break manager, as you can simply use the getBot() method exposed by MethodProvider once context has been exchanged.

I'd recommend creating a new class extending the default BreakManager, override shouldActivate with super.shouldActivate() && yourOwnCondition Then use RandomExecutor#overrideOSBotRandom to register your custom break manager. A few things to note when doing this: - It seems you must also override RandomSolver#getName - You should only attempt to override the break manager when the user has breaks enabled - You should remember to exchange contexts with your custom breakmanager instance before overriding Breaks are enabled when getRandomExecutor().forEvent(RandomEvent.BREAK_MANAGER) is not null

You must override the getName method. Additionally, this will not log you out or draw a paint.. or ever stop breaking again; you have to implement all that logic yourself. Alternatively, to simplify the process, you can extend the existing BreakManager class instead of RandomSolver, in order to re-use the OSBot built in break manager, but simply override when it should activate. This however, will fail if breaks are disabled in client settings, so you must check if there is already an existing break manager registered first; and also don't forget to exchange contexts with your new BreakManager before registering it.

If it's so perfect how come it doesn't work?

If you analyze the outgoing network traffic, you can see that the interact packet only has the index/id of the entity/widget in it (maybe position for objects, haven't tried). The generated packet is the same regardless of where you perform the interaction from, and regardless of where you click.

Why? The point you click isn't sent to the server

Mirror client version: Mirror version: 2.5 OSBot version: 2.5.8 Console output / terminal output: java.lang.ArrayIndexOutOfBoundsException: -5177 at org.osbot.rs07.api.NPCS.getLocalNPC(fe:1) at org.osbot.rs07.api.Mouse.getEntitiesOnCursor(hi:416) Crash report if a crash occurred Script that you ran: FrostBarrows Hooks that failed: Probably XClient#getOnCursorUids JVM/Browser bit version (32 / 64): 32

Thanks for the report. Looks like an issue with reading NPCs from the client in mirror mode. Can you try and see if it also happens when mirroring the official runescape client? I'll post up a client bug report in the mirror mode section EDIT: Do you have the mirror client version and JVM bit-version?

onLoop will not be called while logged out unless you unregister the OSBot Login Handler Are you using the correct CLI args to boot osbot without login handler?

?

There's a link in the OP

There really isn't an argument for "safe" or "not safe". Generally speaking no scripts are safe; if you're unlucky, you'll get banned. If you're lucky, you can be botting strong for months. It's not uncommon for the ones who get banned to leave a post about it, which is fine. Nor is it uncommon for people who don't get banned to not leave a comment.

If you the timestamp of any tick reliant change, you can just use that to find when the next tick will occur. Where did you find GameTickListener and onGameTick() ? These are not specified in the OSBot API

Let's see your implementation of bar in foo? Make sure you specify the type as RS2Object for the first functional interface input (should carry to the chained thenComparing) Comparator.<RS2Object>comparingInt(map::realDistance) Also be aware that sorting all objects by realDistance is very computationally expensive.

You have to be running the script in fixed mode and at default zoom level. By the look of it, one of these might be the cause. Correct, wave 31 I believe it is.

Why not just use the clan wars banking route then? There it restores on the way

Quality post, OP Thank you

There's no simple way to check if an NPC is "visible" in the way you suggest

Yes. It recognizes it as a healing type spec and uses it only when not on full HP

They are up to date AFAIK. You can start it in later waves, but if you do, you must manually ensure configurations of display settings (fixed mode, default zoom), hotkeys (all enabled), and audio settings (effects volume on)

pretty sure you can't have spaces between the args of -allow, but I'm not CLI expert

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