New lightweight Volcano Mining Script! No Object detection! ~3.45K/turn.

P

professorjellybean

Member

Rate update: this script generates 3560 meat per adventure.

Optimize your diets with houeland.


Try it now!
svn checkout https://github.com/AllenTuring/KoL-MineVolcano/trunk

New to Mafia?
- Download the latest build of Mafia: http://ci.kolmafia.us/
- Run it and login
- Open the "Graphical CLI" tab at the top of the main window area.
- Install the script by typing "svn checkout https://github.com/AllenTuring/KoL-MineVolcano/trunk"
- Then, type "minevolcano N" in the Graphical CLI to mine for N turns.
- Kmail me with issues!

Please kmail professorjellybean for issues, since I no longer maintain my own account very much.

-eliteaccordion
 
Last edited:
That file needs to be in a scripts/ folder (or other acceptable folder, but that's the relevant one here) for mafia to accept it. I think .gitattributes just needs to be removed from the project, though maybe mafia just ignores that?
 
Gitattributes is for git only. I deleted it anyway.

Github should support SVN, will be posted shortly. Does anyone know how to do this? They say SVN checkout should work.

Now that I've run it more, I'm seeing around 3.9K/turn. Will start formal logging.
 
Last edited:
xKiv said:
That sounds like it does pretty much the same thing as https://www.reddit.com/r/kol/comments/3jmlrq/my_that_70s_volcano_mining_script/ did/does , except this explicitly limits mining to the first two rows.
(According to the data that old script collected (http://microcoloss.us/cgi-bin/mineResults.py), it had/has 3408 mpa in gold)
Click to expand...

I'll start formal logging to compare.

But I suspect it's a good idea to restrict mining to promising squares in the first two rows, because those have a higher likelihood to contain gold than promising squares in the velvet zone (1.5/9 = 16.7% vs 1.5/15 = 10%)
 
Oh my, good thing I haven't started any logging yet. Found and fixed a bug that leaks turns--after the free reset, I forgot to make mine() call itself to spend the adventure mining. Leaks somewhere around ~30% of turns, I noticed.

Autosold all the golds (24) and got 472800 meat from 80 adventures (based on the mafia readout). Probably an unusually lucrative day for 5910 meat/turn, but will start logging tomorrow.
 
Last edited:
Hm. Considering adding support for Object Detection. The lazy way to do it would be to use Object Detection to select squares in new mines that would otherwise blackout; if there are sparkling squares in the second row, mine underneath those instead of randomly.
 
xKiv said:
That sounds like it does pretty much the same thing as https://www.reddit.com/r/kol/comments/3jmlrq/my_that_70s_volcano_mining_script/ did/does , except this explicitly limits mining to the first two rows.
(According to the data that old script collected (http://microcoloss.us/cgi-bin/mineResults.py), it had/has 3408 mpa in gold)
Click to expand...

Oh huh. That's actually the same process! Since we're doing exactly the same thing, I don't expect the gold/adventure return to be significantly different. On the first day of logging, I'm not seeing anything amiss; after 200 adventures (starting with a 50-adventure dry streak), I'm getting 3.28K mpa.

Current differences:
- I'm accounting for Unaccompanied Miner, both in performance and in logs. If you want to spend 3 turns mining with UA on, you will get 3, not 8--and the log will count all 3 of them. I never reference the player's number of adventures.
- my variables and functions are documented. what is clementine? >.>
- The current version of this script is also broken up in a way that's more readable and can potentially support Object Detection in the future.
- This script checks for requirements each time, and currently handles low health, poor hot resistance, and broken drills. That's the majority of the body of the code. The other script does not.
- My logging is local and in constant space. You accumulate your own statistics and get to judge for yourself. More trustworthy, I would hope.
- A feature I'm striving towards is asynchronous safety. As long as you don't adventure/directly interfere with the script, you can do things simultaneously. You can pull, move things out of closet, buy stuff, etc., do OCD inv. control (if you can figure out how to run it concurrently), change familiars, change gear, eat, drink, craft, buy, sell, etc. If you upset anything important the script is smart enough to revert it or halt with an informative error.

I do like the use of get_property("mineLayout6") though. I didn't know that was a thing. I will consider that for future releases. I hope that will make my performance significantly more lightweight.
I will try that script sometime.

Thank you!

------------------------------------------
Log so far:
Adventures 216
GoldPieces 36
RuntimeSec 281
 
Last edited:
professorjellybean said:
But I suspect it's a good idea to restrict mining to promising squares in the first two rows, because those have a higher likelihood to contain gold than promising squares in the velvet zone (1.5/9 = 16.7% vs 1.5/15 = 10%)
Click to expand...

Well, if you mined all primising squares in the first two rows, and haven't found gold yet, and see a promising square in the third row, then you have already mined at least 2 squares, and probably more, so it's higher than 1.5/15.
In fact, it seems to me that if you have already mined at least 15-9=6 squares, then it's better to continue to third row, otherwise it's better to check next mine.

what is clementine?
Click to expand...

In a cavern, in a canyon, excavaaaating for a mine ...

You accumulate your own statistics and get to judge for yourself.
Click to expand...
(it's not my script)

---

I have noticed that the reddit script seems to visit each new cavern three times before it spends any adventures in it. At least according to logging in gCLI. Presumably yours doesn't, I will definitely check it out.
 
Once to get mine state before reset, once for the reset, once to get mine state after reset? I dunno. Seems unnecessary either way.
 
xKiv, I really appreciate that feedback! I hadn't considered it, but this is what I got in analysis:

Choice: choosing to mine a 3rd-row promising square.
In that case, you must have gotten 2 whammies/healing crystals... so the balance for a new Square in row 3 is one of the following:

1.5 nuggets of 1,970s carat gold
5.5 crystals/lava collapses
6 velvets.

Therefore an average of 1.5/13 or 0.11538 golds.

On the other hand, a free reset yields:

None in the first line: P(None in first line) = (24/30)*(23/29)...[9 terms] = 24!21!/30!15! = 0.091388 of the time. (Worthless.)
The probability of having a shimmering square in the first row is therefore: P(At least one in first line) = 1 - P(None in first line) = 0.908612

This new square gives one of the following:

1.5 nuggets of 1,970s carat gold
7.5 crystals/lava collapses

Which yields an average of 0.166666667 gold per square. Since this occurs 0.908612 of the time, the free-reset choice provides an average of 0.151435 golds.

Therefore:
Free reset instead of taking the newly emerged promising square yields 0.151435 golds.
Taking the newly emerged promising square instead of free reset yields 0.11538 golds.

Since ignoring the third-row square yields less average gold, it's not worth taking--the free reset is the better strategy.

Thank you so much, though! This is good to know.
 
xKiv said:
(it's not my script)
Click to expand...

I know. What I mean is the current version should provide lifetime logged statistics at the end of each session, and the raw data used to calculate this (ints-only, exact) is stored under data/pjbminer_data.txt. This is your data, so you don't have to rely on me to tell you how well the script is doing.

This is going to be helpful because I may introduce Object Detection support, which should give (some unknown edge) to the script algorithm. And because my script differs from the spaded Reddit script in that it plays nice with Unaccompanied Miner.
 
Last edited:
xKiv said:
I have noticed that the reddit script seems to visit each new cavern three times before it spends any adventures in it. At least according to logging in gCLI. Presumably yours doesn't, I will definitely check it out.
Click to expand...

Possibly? I sincerely hope I'm only loading once as often as necessary. If you're having an exceptionally bad day (no promising squares, all immediate free resets) then I expect it to be at most 2 adventures/visit. Please let me know if this is not the case.

The honest answer is the Reddit script, while I admire greatly, would take me a few hours to fully understand. I'm not yet to that level of concise code yet.
 
heeheehee said:
Once to get mine state before reset, once for the reset, once to get mine state after reset? I dunno. Seems unnecessary either way.
Click to expand...

So right now the script does 1 mine-state-check (via the function refresh) right before actually mining, once it's verified that you're qualified to mine (assuming you have access). If it free-resets, it recursively calls itself. So what happens is:

In case of a free reset:

mine()
|-> Assuming 70s volcano access, check if we can mine (halt/fix if we can't).
|-> refresh()
|-> This mine is neither freshly reset nor presents any sparklies. I need to reset.
.... |-> mineReset()
.... |-> mine()
........ |-> check access. // Should still be okay, but never hurts--maybe user unequipped something important.
........ |-> refresh()
........ |-> This mine is freshly reset. // It is impossible that another reset will be needed, so no nasty infinite loops.
........ |-> mineAt(target[0], target[1]); // Hit the identified sparkly.
............ |-> did we get gold?
................ =? yes : mineReset(); // Yay! give me a new mine for future iterations.
................ =? no : // well that's just sad. but an adventure has been spent. Must quit.
................ return
............ return
........ return
.... return
return

1 adventure spent.


(The bold part is what happens under normal mining circumstances, when a free reset is unnecessary)

So... I think, if my code is correctly implemented, and the wiki is correct, it only checks the state of the mine if and only if the state is unfamiliar/has changed and you are all prepped to go. (If this is not the case, please let me know--I don't want to make you all pull and process webpages unnecessarily.)
 
Last edited:
Actually, you're not taking into account how the velvet vein is grown, which pushes the average number of velvets in row 3 far below 6. A script I wrote a while back claims that the expected number is about 0.7 (by calculating probabilities and weighting appropriately), but I'm not sure if I trust it. I also don't think that the number of gold is quite a 50/50 split between 1 and 2.
 
professorjellybean said:
Choice: choosing to mine a 3rd-row promising square.
In that case, you must have gotten 2 whammies/healing crystals...
Click to expand...

*At least* 2. There's no guarantee that each row will have at most one.
The choice should be dynamic for each mine (and I expect that it won't probably even be necessary for most mines - if you find the gold in first two rows, or there's no sparkly path from 3rd row to 1st row)
 
You must log in or register to reply here.
Back
Top