Popular Post Apaec Posted May 10, 2017 Popular Post Posted May 10, 2017 (edited) $9,99 for Lifetime use Visit the store HERE! Script Features: Highly customisable solving - continuous solve speed slider and a range of solve order modes Ability to choose exactly which runes to buy (with option to buy all runes without opening store) Real-time profit tracking with live exchange data to accurately model your profit estimates Web-walking - the script can be started anywhere, and will make its own way to Ali Morrisane Quick and easy to configure re-sizeable setup GUI Informative self-generating paint with hourly rate data displayed Smart Sudoku solving logic and board data reading means the script will never fail a Sudoku Error correction - the script can determine and overwrite incorrect rune tiles if necessary Mouse teleportation - If desired, the script can be configured to teleport the mouse between squares to solve sudokus at rapid speeds Optional debug settings show the Sudoku solve process and upcoming generated moves Stops and logs out when out of money to spend Rune Sudoku Requirements: Rune Mysteries Quest The Feud Quest 30 Thieving Start the Rogue Trader Minigame (details below) Before automating the solving process, you will have to start the Rogue Trader Minigame and solve a single Rune Sudoku puzzle. To do this, after the two above quests have been completed, talk to Ali Morrisane, agree to help him, then talk to Aubury in Varrock rune shop. Then, after returning to Ali Morrisane, the script can be started (note that there will be a slightly extended dialogue for the first solve). Things to consider before trying/buying: Due to the nature of this script, it can be considered quite risky to use, especially on the faster solve speed settings - a human would struggle to keep up. However, as we enter the era of third party clients with graphical overlays, the lines between humans and bots for puzzle solving draw closer - provided you use the script carefully with sensible precautions in place, this script should be no riskier than any other. Conditional vs. Unconditional solving - To allow you to personalise your session settings and ensure that the script runs differently every time you start the script, I added a continuous solve-speed slider on the startup interface. This slider, beyond a certain threshold, makes the script run in unconditional mode. This mode means that the script will move on to the next queued action before verifying that the previous action executed correctly. For example, when placing runes, the script will place one then move on to placing the next before ensuring that the previous one was placed correctly/successfully. Why would you want this? Well - when you click to place a rune, that rune appears on the next game tick. As a result, after clicking a rune tile, it can be up to 0.59 seconds before appearing which is 0.59 seconds the script can be doing something productive other than waiting! This means that solve speeds rapidly increase, however there is a very small - but present - chance for error. While this error is not a problem as the script has error-correction (the script will not get stuck no matter what state the Sudoku is in!), this may slow you down based on your latency. Try out different speed settings and see what works best for you! To ensure maximum efficiency, I would highly recommend enabling the 'Esc closes current interface' box in the Keybindings menu: The script uses the OSBot web-walking system. While it has proven very reliable, there are naturally some areas for which the web-walker may struggle. Prior to starting the script, I would recommend manually navigating your player to Ali Morrisane, who can be found here: Script Trials: I believe that trying a script before buying is paramount, however due to the high profitability that this script provides I am limiting the one-time trials to 12 hours in duration. If you're interested in a trial, please follow the instructions on my trials thread which can be found here. Progress reports: Spoiler If you have an awesome screenshot to share please post it to this thread and i'll add it here! Updates: Spoiler 2021-05-15: Script updated to work with new sudoku board: Old: New: Development process: Spoiler 5-May-2017 I started the project by writing the sudoku solving logic. The goal here was to be able to enter an unsolved sudoku puzzles into the software, letting it process the puzzle and then put out the solution. The unsolved board is processed with a simple recursive brute-force algorithm (with illegal-move pruning) - there are more efficient ways, however since this process is almost instant, it will not prove to be a bottleneck while the script is running. Also, with this method, a solution is guarenteed. While it may not look like much, it took several hours to get the code base in place in order to solve the first number-based sudoku (an exciting moment!): 6-May-2017 While having a simple text based output works just fine, I wanted to make a simple interface which would display a sudoku board. This interface would make future debugging significantly easier - below is an example of the first version of this interface displaying the same puzzle as before. 7-May-2017 With a basic interface in place and the sudoku solving logic behind it, I considered myself ready to venture into OSRS and start converting this system into a script. I had originally hoped that the grid would be nice and easy to read with either sprites or widget ids, however much to my dismay this was not to be! (or atleast the widget debugger didn't pick anything up - I didn't dig beyond that). It seemed to be the case that I could not scrape any data from the second level widgets, not even where empty slots were. While this set me back a bit, I realised there was a clear solution: the colour picker. The colour picker allows you to examine pixel colours at specific screen co-ordinates. This allowed me to write a system which analysed each rune tile and determined the count of a specific pixel shade in that tile. I implemented this to read the value of a specific shade of grey (a colour which all rune tiles shared), and here's the data that I was looking at: Much to my satisfaction, it turned out that each rune had its own unique grey-count, albeit that some counts were very close to others. I then used this to recognise the runes: It seemed to work! I could then use this information to learn what is on the board, convert each rune into a value, visualise this value and determine a solution to the sudoku: 8-May-2017 Unfortunately my excitement was short lived. Firstly, this colour reading only works on a specific brightness setting. While this may not seem like a problem (it didn't to me, this is easily solved by making the script adjust the brightness if necessary), there was an added complication: in presumably an attempt to prevent colour bots, every time you adjust the screen brightness or re-log, a random colour filter is applied to the game screen acutely altering all r g b values by small amounts. While this filter is not noticeable to humans, it completely throws off the bot. Argh. In an attempt to combat this, I tried adding a threshold checker to the colour values, however this did not help as no matter what the threshold is, it can still be foiled by jagex's filter overlay. (The variance of grey throughout the rune was too much not to read other values). This meant that I had to re-think how I was recognising runes, and I concluded to search for each rune individually - most runes have very distinct features (such as the red fire rune symbol), so I figured that if I could search for those, it would be slightly slower but would be guaranteed to work. I determined the key features for each rune, and then searched each cell until a matching rune was found. Since empty cells are the most common when a sudoku is analysed, I check for them first (the first and second row of numbers, since the board is orange/yellow checkered). Each further level corresponds to a rune colour check, for each of the cells in the top row. Apart from a few calibration issues which resulted in death runes being confused with air runes, this system works for every colour filter jagex can apply to the full brightness setting. Success! The board is now read successfully every time. Now for the solving. 9-May-2017 Since the hard stuff has been done all I had to do was determine what has to go where and then place it. If I did this all in a for loop, which is the temptation, the script would fall away from its continuous looping nature and would not be happy if stopped mid-solve. To combat this, I implemented a rune placement queue which is modified as the sudoku is being solved so that a clear set of instructions exist for the solver to execute. This also gave me freedom with how the sudoku is solved - I could simply modify the order in which rune placement instructions were generated. Rune by rune, tile by tile, completely random? no problem. After some calibration, a lot of testing and some details that I won't bore you with, I was left with a fully functional rune sudoku script. I ofcourse added all the essentials - a paint, resizeable gui, real-time profit tracking, solve rate tracking, adjustable solve speed, custom store buying, game brightness handler and much more. Oh, and I should mention that it should never fail a sudoku. No matter if you fill the board with random runes, it will always correct any mistakes that it finds. 10-May-2017 Performed lots of test runs. Script is working very reliably! Below is a gif of the script in action. 13-May-2017 (Part 1) There are few bits of the script that I was not very happy about. Firstly, the half second pause between opening the sudoku and generating a solution was not ideal for me. While it wasn't too bad, it was something that, given some tweaks, could be minimised. To go about adjusting this, I had to determine the cause of the delay, which I believed to be having custom pixel rgb data for each rune. While this is a working and reliable solution, it means each cell has to be - in the worst case - scanned up to 10 times. Not ideal! Instead, to solve this, I decided to once again check for grey, but this time set the threshold wide enough to encompass the entire rune background. This allowed me to determine runes based on the space their logo takes up on the base of the rune. There are, however, a few issues with this approach which is why I did not initially explore it at the start. Firstly, the whole tile has to be analysed before a decision can be made as to what rune it is. Secondly, the '1' showing that the rune is editable overlaps slightly with the rune, meaning editable runes have slightly different thresholds to default ones. Finally, the death and air thresholds are only 1 pixel apart! (Editable runes are the top row, provided runes bottom row) That being said, it had some obvious advantages: Firstly, tiles only had to be scanned twice (once to determine if editable (this was being done anyway), second time to determine the rune). Secondly, the colour reader could potentially work on multiple/all brightness settings. Finally, the runes did not have to be in a hierarchy as they all share the same base colour. The second thing that I wanted to do was cut out the middle step of converting runes to numbers and numbers back to runes (this happened while generating a solution for the permutation of runes). While this was a valid approach which wasn't very time consuming, it was simply untidy, unnecessary and very avoidable. To solve this issue, I made the sudoku board data structure generic (which I should have done from the start) provided the type it is given is comparable. Since the rune data is stored in an enum, this worked out nicely as I did not need to write my own compareTo method. This also means the sudoku viewer can now display the rune values instead of arbitrary numbers: 13-May-2017 (Part 2) Just thought I would drop in a second part to the progress update for today. I've finished implementing all that I mentioned above, so the solver is much more efficient at reading the board. Additionally, I've modified the UI a little to cater for some debug options: I feel at the stage where the script is complete, and ready for release! I've completed many many many sudokus with the script and I have to say it was great fun writing it. Here's the final solving logic with the same settings as the ui above: 13-May-2017 (Part 3) Submitted an SDN Application for the script. Before submitting the application, I had to decide the price. I knew that I wanted to make this a premium script for a couple of reasons - Firstly, the ban rate. It appears to be the case that the more users a script has, the 'higher' the ban rate - if this script were to be very cheap or free, it would be overused and the risk to all users would increase. Secondly, the method would lose considerable profitability if overused - having a filter price would mean enough people could access the script should they need, but not too many as to impact market prices. Finally, I spent many hours developing this script and it would be great to get something back (albeit very little)! Considering aforementioned factors, I concluded $9,99 would be a reasonable price to ensure only a handful of individuals would run the script and the risk would remain comparatively low to all. Edited May 15, 2021 by Apaec 51
xLoCo Posted May 10, 2017 Posted May 10, 2017 This will be some nice profit considering the price of deaths at the moment. Nice work my man 1
Apaec Posted May 10, 2017 Author Posted May 10, 2017 40 minutes ago, xLoCo said: This will be some nice profit considering the price of deaths at the moment. Nice work my man indeed, i'm getting 440k/h 1
Gleets Posted May 10, 2017 Posted May 10, 2017 don't you get insta banned when doing this?when i was trying this,i would get insta banned after 2 puzzles. 1
Apaec Posted May 10, 2017 Author Posted May 10, 2017 (edited) 9 minutes ago, Gleets said: don't you get insta banned when doing this?when i was trying this,i would get insta banned after 2 puzzles. Depends how fast you solve it I suppose. I've not had a ban while writing this script and that means having solved at least 500 puzzles. I think the randomised order in which this script can solve it also helps, as well as the customisable solving speed. Nevertheless, it is by nature a high risk high reward activity! Cheers -Apa Edited May 10, 2017 by Apaec
Gleets Posted May 10, 2017 Posted May 10, 2017 11 minutes ago, Apaec said: Depends how fast you solve it I suppose. I've not had a ban while writing this script and that means having solved at least 500 puzzles. I think the randomised order in which this script can solve it also helps, as well as the customisable solving speed. Nevertheless, it is by nature a high risk high reward activity! Cheers -Apa that's great,i'm looking forward for this script 1
Apaec Posted May 10, 2017 Author Posted May 10, 2017 2 minutes ago, Botre said: Loved reading this. Nice work, old friend. I wouldn't be here without you!
