FrostBug

I ended up writing a sortof custom variation of the IDA* algorithm to use a minimal amount of memory (Using only one state instance, performing and undoing moves on it as needed from a recursive algorithm). My first approach using plain A* resultet in often running out of memory before reaching a solution, so I had to scratch that :E.

PM me if you have a puzzle box that isn't the Grand Tree one btw; I'll pay you 1m if you debug it for me. I'm 95% sure the script will work for all box types; but I want to be 100% sure.. EDIT: Solved

Version 1.0 Features - Solves Treasure Trail puzzle boxes - Solves Monkey Madness puzzle Requirements - A puzzle box of any type Starting the script 1. Open your puzzle box 2. Start the script Note: Yes, the puzzlebox must be open before starting the script! Proggies I don't really think this is relevant; but whatever Notes The script uses an implementation of the IDA* algorithm. The time it takes for the script to calculate a solution to each stage of the puzzle can vary depending on the "luck" with the puzzle box randomization as well as processor speed. If your luck is bad, the script may appear stuck calculating for a couple of minutes; however, given enough time, the algorithm will always reach a solution. In some cases however, it may be faster to simply relog (relogging re-randomizes the puzzle) and run the script again. The script is available for free on the SDN

Starting both now

Version 1.4.1 - The script now remembers which tomb leads to tunnels after exiting the tunnels prematurely - It is no longer supported to start the script with all 6 brothers already dead _____ Thank you guys for the reports, and sorry for imposing additional restrictions upon starting the script. I will update the "Starting the script" guide in the OP to hopefully avoid too much confusion. NOTE: This patch is not live just yet!, the SDN manager will have to review it first. Once the patch is live, "version 1.4.1" will be logged in the client console at script start. It should be live within 12 hours at most.

Not at this time. I only added it because it was requested on a daily basis tho..

A new patch is now live that fixes the tunnel solver state in the case of all brothers already being dead. It's most likely missing an item. Check the console output. EDIT: If anyone still experience any problems with client crashes, please see if you can manage to do a screen capture of the client (with console open) and post it here. I still haven't been able to reproduce this problem.

Thanks; I'll fix the issue of not dealing with coming back to 6 killed brothers. This too is an issue cased by the update earlier this week This can be solved by putting all of your required resources in a seperate tab, including all the dose variations of your selected potion. It's because bank scrolling still does not function in the mirror client. Can anyone confirm if this is happening only on mirror mode? Haven't been able to reproduce it on the standard client.

Added a 6 hour trial

Version 1.4 - Script rewritten to work without the now removed clientside information - Dynamic signatures are now updated again - Added some handling for the new loot widget ______ Unfortunately it is no longer possible for the script to simply look up which brother is going to be in the tunnels; this means that I've also had to remove the option to "Always check the correct tomb last". I'll look into alternative ways of re-implementing this in the future

Pretty sure that IS loaded correctly; jagex probably uses that format and splits it by "|" In best case I suppose a method could be added to suit specific needs

Well, okay. But I meant mainly in terms of being easier to maintain. If you're creating 3 custom filters with the same checks in 3 different places, you'll have to update all 3 of them if something changes ITT: Overanalyzing :p

Well, you don't need to re-create it if you simply construct the filter and assign it to a global member; as such public Filter<> filterInstance = new Filter<>(){ .. }; But it certainly helps if you're using the filter across multiple classes and such. As soon as you need to construct an instance of this custom filter in more than 1 location, I would definitely not recommend doing it anonymously twice.

Update With todays update, Jagex removed a ton of "client-side information" that the script used for a lot of things (Puzzle solving, Tunnel pathfinding, Ladder locating, Determining which brother is in the tunnels etc.) Unfortunately it's probably going to take a few days to rewrite the script. I will keep you guys updated on the fixing progress.. Patching status: - New puzzle solving methods - New method to determine ladder location - New method to determine tunnel brother - New method to deal with loot interface - New methods to find the correct path to the center - New methods to determine tunnel states - Extensive testing of new changes

Gonna post this again since we're on a new page now .. :E Warning I need to update the script to work with the changes that were made to the barrows minigame in todays game update. Until the script is updated, please know that the script will more than probably get stuck! I will start fixing it as soon as I get home from work

were*

I don't yet know the extent of what jagex changed. But I will start working on it as soon as I get home from work.

Considering you've received TWC, could paypal have charged back the VIP payment for some reason?

Warning I need to update the script to work with the changes that were made to the barrows minigame in todays game update. Until the script is updated, please know that the script will more than probably get stuck!

@OP You don't have to make a seperate class for the filter as I suggested; that's just my own personal preference, as I find it cleaner and better for code-reuse. The only actual difference is that you don't get the context snapshot, which wasn't needed in my example.

What am I reading o_O this whole thing is literally the same as if(npc == p.getInteracting()) { return true; }

Are you certain of that, tho? It might be silently caught out back

What's that logging code? Might it be throwing the error? Try surrounding all of it in a try-catch, and use the default osbot logger to log the error

public class YakFilter implements Filter<NPC> { public boolean match(NPC npc) { return npc != null && npc.getName().equals("Yak") && npc.getHealth() > 0 } } ^ Use a custom filter to find the yaks that aren't dying Can be used like so: NPC yak = getNpcs().closest(new YakFilter());