Jump to content

APA Rune Sudoku


Apaec

Recommended Posts

  • 1 month later...
On 11/11/2021 at 2:35 PM, happy Rasta said:

How are the ban rates?

I'd consider this script fairly high-risk as it is solving sudokus far faster than humans would. However, as it's a method that is not used much, it's probably not as risky as you think.

Be sure to use generous breaks, play legitimately between sessions and don't exceed a couple of hours per day. You should be fine if you bot cautiously :)

-Apa

Link to comment
Share on other sites

  • 5 months later...
On 11/13/2021 at 1:17 PM, Apaec said:

I'd consider this script fairly high-risk as it is solving sudokus far faster than humans would. However, as it's a method that is not used much, it's probably not as risky as you think.

Be sure to use generous breaks, play legitimately between sessions and don't exceed a couple of hours per day. You should be fine if you bot cautiously :)

-Apa

hello sir , i have a question about your script . if the script runs out of GP will it log out itself?

Link to comment
Share on other sites

  • 1 month later...

Recommended! 

Works flawless on injected / mirror mode, ran them roughly for 4hrs and have had a total of about 8, for bout 236k/h with the fastest mode (w just cosmic runes being ~280% profit)

There's still a big diff between one way of completing the puzzle and another, lag, etc but as a starter it looks like a solid script! Will see if it pays for itself tho

screenshot-04-07-2022-18-47-18.png

  • Heart 1
Link to comment
Share on other sites

  • 5 months later...
On 5/10/2017 at 5:15 PM, Apaec said:

NKbnU01.png

$9,99 for Lifetime use

Visit the store HERE!

w6Rxn7d.pngZxq2N5a.gif WsnfJz2.png

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:

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:

JHeIIhS.png

  • 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:

4BJMdNf.png

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:

  Hide contents

If you have an awesome screenshot to share please post it to this thread and i'll add it here!

IEj3Wyz.png

Updates:

  Hide contents

2021-05-15:

  • Script updated to work with new sudoku board:

Old: KbIVgIU.gif

New: Zxq2N5a.gif

Development process:

  Hide contents

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!):

dL7DgK9.png

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.

IhNJZ5I.png

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:

nUZnTTY.png

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:

w7TNhaY.png

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:

uFYlSLv.png

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.

amkSNCq.png

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.

Solve7.gif

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!

 HOKLXji.png (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:

tRg4F1e.png

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:

8VxrXBB.png

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.

i am thinking to buy its looks cool can i get a trial

 

 

 

Link to comment
Share on other sites

  • 4 weeks later...
  • 2 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...