FrostBug

Not sure if still relevant, but a way to get the general uptext is: /* * Get the mouse uptext */ public String getUpText() { List<Option> menu = getMenuAPI().getMenu(); if (menu != null && !menu.isEmpty()) { return menu.get(0).action; } return "Cancel"; } Despite the nature of the code, it does not require you to have a right-click menu open.

You can send key events directly to the client in order to have the mouse click at specific coordinates (and jump there). eg. ClientMouseEventHandler meh = getBot().getMouseEventHandler(); meh.generateBotMouseEvent(eventID, timeOfEvent, modifiers, x, y, clickCount, popupTrigger, buttonId, botEvent); The class uses AWT events, so you can poke around the oracle AWT docs for more info on IDs and such.

getClient().getLoginState() != LoginState.LOGGED_IN

It is, though.

Updated the mirror client entry in the FAQ. Hopefully that'll decrease the mirror client request spam

Have my babies, sir

your* How is that relevant ;o ?

Looks pretty nice Inb4 make and correct typos

It's nice, but I like the current one better. Nay

That may work, but only while you're not focusing on the man as well (eg. will not work right before you pickpocket the man, while the player is focusing the man). What you could do instead is simply check if your own player is under attack. If both you and the man are under attack, you'll be the one attacking him. If the man is under attack, but you are not, then it's probably someone else.

If the sole purpose is to check if YOU are the one attacking the man, then you could just do: if (man.isUnderAttack() && !man.equals(myPlayer().getInteracting())) //I'm not attacking the man if (man.isUnderAttack() && man.equals(myPlayer().getInteracting())) //I'm attacking the man For the second case tho, you should probably add some more checks (We ARE in combat / the man is also interacting with us), in order to prevent any confusion that could occur if someone else is attacking the man, but we're still interacting with it for whatever reason.

Lol, I hadn't even noticed that. There will be a client config (VARP) that you can read the value from directly, then (most likely). Try using the client config debugger

implement the onMessage method in your Script class. void onMessage(Message message) { if(message.getType() == MessageType.GAME && message.getMessage().contains("damage absorption left")) { String[] parts = message.getMessage().split(" "); try { int pointsLeft = Integer.parseInt(parts[3]); } catch(NumberFormatException | ArrayIndexOutOfBoundsException ex) {} } } NOTE: Typed it out without an IDE. The syntax may be faulty.

Started

Not possible But there are plenty of ways to make guesses; eg. tracking what items you've dropped

On OSBot, the number of accounts you can run depends not on the script, but your OSBot account. Regular users can run 2 accounts, while VIP users can run unlimited numbers.

In Eco-Cat we trust

If you do have a path, you could just keep walking to the loaded position closest to your target destination. As you reach that position the next regions should load. Also, localWalker walk methods aren't asynchronous, so there shouldn't be a need for a conditional sleep after invoking it.

#1 Issue really is entity update speed. Tho I fear that resolving this issue will further strain the CPU usage. Due to the nature of the mirror client, I am not really certain that it's at all possible to reduce the CPU usage by a whole lot. But it would be nice to get a word on this from @MGI For the record, the requirement of being logged out as you hook the client is part of the How-to-run mirror client guide; so I don't really think it belongs here. There are probably some circumstances related to that.

Ensure that your main class has a reference to the GUI instance. Then do as @Precise said.

It seems a bit silly to ask us about a walkTo method that you seemingly wrote yourself, and haven't provided the source for in this post. If however it uses some of the standard localWalker or WalkingEvent API, then the pathfinding is limited to the currently loaded region. Also, offtopic, but sequential execution like that is quite bad. Try to set it up to not rely on the previous action to have completed successfully. Easily done by ensuring that only 1 thing is done in every loop cycle.

Started It's there. Please submit a bug report using the template from the OP if it isn't working as it should.

If there is a chat message, you can listen for that. if there is XP gain, you can calculate it from that.

Version 1.2.4 - Patched an issue with shield-unequip at trident recharge

if you just want to interact with it, you should use a MouseDestination implementation with the rock, and grab a suitable point from that. if that's not what you're looking for; something like this should give you the center of the rocks bounding box Rectangle bounds = rock.getModel().getBoundingBox(rock.getGridX(), rock.getGridY(), rock.getZ()); Point center = bounds.getLocation(); center.translate((int)bounds.getWidth() / 2, (int)bounds.getHeight() / 2);