FrostBug

nice XDDDf

XDDDf

pfft Netbeans UI builder > Eclipse UI builder

MGI announced an eta for the patch for this particular issue with the 1.055 news post. It was scheduled for last weekend, but is seemingly running a bit late. The problem in itself is that the entities are not immediately available to the client after spawning/loading/changing. If you however wait a few seconds after loading the new region, they should be perfectly visible.

Indeed, if you fill out the bug report template, I could probably identify and fix the issue. If you hurry, I may be able to include it in the patch scheduled later today

No idea , I have no access to the auto-login event. This should be posted in the client bugs section.. But it probably already has been by now if it's a replicable issue

Wrote some patches, but unfortunately I won't be able to finish testing them today. They should be out tomorrow, though.

Script version 1.0.5 - Fixed a bug related to directly raising fallen traps The new version should be live on the SDN within the next couple of hours _______ Adding

Hmm, I personally prefer FSM styled frameworks (state transitions) in comparison to these node frameworks which require evaluation of state in every loop cycle. But definitely an interesting approach to improving their potential Are you working on any scripts? I am quite interested in seeing what you could produce

The fact that it turns on auto retaliate in the first place was a sort of workaround for the inability to determine which brother is yours, if multiple of the same barrow brother are stacked on top of eachother :| As for the timeouts, they're a sort of anti-stuck measure you could say. Instead of just calling the default interaction methods normally, I call them asynchronously, while keeping a timer on it. Interrupting the event if it hasn't finished within a certain time limit (3000ms or 5000ms typically). Did I not interrupt them, the interaction methods themselves would probably keep trying/failing for a longer time until timing out internally. I do not know why it didn't recognize your ring. But, such things are most often caused by disconnections. If you had disconnected right before the incident, it is possible that it failed to properly read the contents of your equipment immediately after logging in. I actually do have some methods to counter this, just not implemented everywhere in this script yet. I will do so for next update

Sure, do you want one now?

Started

There should be a workaround for the banking issue live now with version 1.2.6a

If a developer is gonna provide an update on it, they will provide it here The spell is Lumbridge teleport, not Home teleport. Home teleport would get interrupted by combat and falling rocks in the tunnels. Thanks. I'll have it fixed asap As I've already said, it is a client bug. you can track the issue here

Should be fixed, yes. I believe the cause was the change in data orb widgets, which made it fail to select quickprayers. So far so good

What tunnel solving issue? Probably not true.. who told you it was?

You can get it now if you want, but like I just mentioned, banking will be down until we get a patch from the devs. Drop me a PM if you still want it now

The new version needs to be reviewed by the SDN Manager before it can go live on the SDN. He typically does this 2-3 times per day.

Version 1.2.6 - Updated data orb widget values - Fixed an issue with puzzle-door interaction NOTE: Some banking features are still broken!, I've submitted a bug report to the client developers, so hopefully we will see a patch from them very soon. Banking will not work properly until then

Looks like a widget related hook has broken with client version 2.3.72. Will look into it tomorrow Also for future reference, use the template from the OP..

You can get a 2d array of tile flags by XClippingPlane[] planes = getMap().getRegion().getClippingPlanes(); each plane has a getTileFlags() getter for the int[][] array of flags (index by local coordinates). I'm not sure what the flag values are, but it should be fairly simple to debug

This doesn't really solve the main misclick issues, though. Just like the method in the API, it lacks a check for whether or not the menu is still open before clicking (At least the API method used to lack it. I am not 100% certain that it still does). Due to the nature of the mouse algo, the path taken to the option can sometimes lead to the mouse getting too far away from the menu, closing it on the way. I made some API methods for interaction with this last check about a year ago, will probs post in snipper section when I get home Offtopic, using while loops without any form of timeout is generally a bad idea

To get the rectangle for a menu item (Eg. "Walk here"), you can do something like this: getMenuAPI().getOptionRectangle(getMenuAPI().getMenuIndex(null, new String[]{"Walk here"}); I don't remember if it allows null for entity names, though. If not you can just iterate the Option list to find the index of whatever option you want.

If you have the actual font file, it would be easy to determine the dimensions of any given string, using fontmetrics or glyph vectors. A Graphics object should provide access to these. If you just want to calculate an area in the rs right-click menu, you can easily do so by using the MenuAPI class

Add some debugging to your code to figure out what's going on. If onLoop is getting called frequently while "breaking", then it's an issue with your script. If it isn't, then try to figure out where the thread is stalling Pretty much what Flamez said.