Page 2 of 5 FirstFirst 1 2 3 4 ... LastLast
Results 11 to 20 of 44

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

  1. #11

    Default

    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.

  2. #12

    Default

    That sounds like it does pretty much the same thing as https://www.reddit.com/r/kol/comment...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)
    Originally Posted by xKiv View Post
    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 by professorjellybean; 01-07-2016 at 05:27 AM.

  3. #13
    Senior Member
    Join Date
    Apr 2009
    Posts
    1,812

    Default

    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%)
    Originally Posted by professorjellybean View Post
    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?
    In a cavern, in a canyon, excavaaaating for a mine ...

    You accumulate your own statistics and get to judge for yourself.
    (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.

  4. #14
    Developer
    Join Date
    Aug 2009
    Posts
    2,796

    Default

    Once to get mine state before reset, once for the reset, once to get mine state after reset? I dunno. Seems unnecessary either way.

  5. #15

    Default

    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.

  6. #16

    Default

    (it's not my script)
    Originally Posted by xKiv View Post
    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 by professorjellybean; 01-08-2016 at 04:02 AM.

  7. #17

    Default

    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.
    Originally Posted by xKiv View Post
    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.

  8. #18

    Default

    Once to get mine state before reset, once for the reset, once to get mine state after reset? I dunno. Seems unnecessary either way.
    Originally Posted by heeheehee View Post
    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 by professorjellybean; 01-08-2016 at 04:28 AM.

  9. #19
    Developer
    Join Date
    Aug 2009
    Posts
    2,796

    Default

    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.

  10. #20
    Senior Member
    Join Date
    Apr 2009
    Posts
    1,812

    Default

    Choice: choosing to mine a 3rd-row promising square.
    In that case, you must have gotten 2 whammies/healing crystals...
    Originally Posted by professorjellybean View Post
    *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)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •