BeachComber - fast and efficient beach combing

Currently, this will go to a random beach section every turn. I'm considering a mode of operation which will repeatedly go to the same section to collect 't' squares, until there are none left, before moving on to a different section.

Pro: Every time you go to a different section of beach, there is a chance that it will be cleaned out of 't' squares. Collecting in the same section until it is fully collected will alleviate some of that chance, since we'll be changing sections less often..
Pro: We don't know about the distribution of 't' squares within a beach. I don't find sand dollars or fish scales to be as interesting as equipment, say. Is there always a "higher quality" drop in a beach section, or is it purely random? I suspect the latter, but if the former, fully harvesting 't' squares in a beach section will potentially give you a better haul
Con: Cleaning out all the 't' squares is exactly how the next person to randomly visit the square doesn't find any 't' squares. Which is to say, it is selfish, rather than cooperative.

I may or may not do anything like this, but be aware that I can and do make commits for any reason. For example, the last one also fixed a typo in a message, and even if the new discovery hadn't been announced, I might have submitted that change alone, and your local mods would be discarded for something you probably wouldn't have cared about.
 
in /scripts... didn't expect an update of the script after 4+ months... :(

If you know about the feature that would protect you and choose not to use it then OK. My comment was for those who did not know.

See Revision Merging at https://wiki.kolmafia.us/index.php?title=SVN_Primer

The way I was saying it, I actually meant it as "why I didn't keep a backup of my changes". I DID NOT know about the merging feature, and should keep this in mind in the future!
 
Is it possible to add a feature to let you only use a certain amount of your free combings? (For if you plan to comb some beach heads later on)
The argument parsing is super primitive currently.

Code:
    int turns =
	command == "free" ? 0 :
	command == "all" ? my_adventures() :
	command.is_integer() ? command.to_int() :
	-1;

    if ( turns < 0 ) {
	print_help();
	exit;
    }
To allow

BeachComber 3
BeachComber free
BeachComber all

It wouldn't be too complicated to allow something like

BeachComber 5 free

Or, to enable new options:

BeachComber specific 842

(to go to 842 minutes)

BeachComber 5 free twinkles

(to use 5 free turns focusing on rough sand with a twinkle)

Right now, I'm working on the "go to the same square multiple times to get twinkles" feature.
 
Revision 214 does this:

set VBC.PickStrategy=twinkle

... will behave as described above.

start by going to a random beach section
while there are twinkles, pick them
rinse and repeat

I'll look into making the command parsing more capable, by and by.
 
Since KoLmafia now automatically marks the square you just combed with a 'c', this script doesn't need to do that any more.
This eliminates KoLmafia's logging that the _beachLayout property has changed.
It only does that if a script changes a built-in property, not if KoLmafia itself changes a property.
 
It seems that every tile has a permanent set rarity (see https://kol.coldfront.net/thekolwiki/index.php/Comb_the_Beach), and is re-combable after a certain amount of time (more rare, more time to reset). It might be a good feature to at least build a map of which tiles have which rarity. In the future it might also be cool to have a strategy that revisits certain tiles after they have probably reset, or at the very least farms them if it notices they've reset while happening to visit the same part of beach.
 
I'll think about that. It's especially appealing considering what I encountered today. I'm glad I made this script save the HTML for "special" combings.
I can now confirm that "whale.png" is titled "a beached whale".

Screen Shot 2020-08-18 at 5.23.37 PM.png
 
The past few days, I've been running into a little issue. Using the script menu to call beachcomber and entering 0 in the little thing that pops up to put a number in, on the first time it's done per day: it gives this error message: e1dfe7566837ed32319aaf977a4aaed0.png
However, doing the exact same thing a second time after that, it combs the free comb limit just fine.
 
Fascinating.

Code:
Starting ASH script: BeachComber.ash
All is well!

Requesting: https://www.kingdomofloathing.com/main.php?comb=1
Retrieved: https://www.kingdomofloathing.com/main.php?comb=1
Field: Location = [choice.php?forceoption=0]
Requesting: https://www.kingdomofloathing.com/choice.php?forceoption=0
Retrieved: https://www.kingdomofloathing.com/choice.php?forceoption=0
ResponseText has 17012 characters.
(whichchoice=1388)

Starting spading script: excavator.ash
Connecting to https://zachbardon.com/mafiatools/autoupdate.php...
Requesting: https://zachbardon.com/mafiatools/autoupdate.php?f=use_for_items&act=getver
Retrieved: https://zachbardon.com/mafiatools/autoupdate.php?f=use_for_items&act=getver
ResponseText has 25 characters.
<font color="black">You have the latest use_for_items.txt.  Will not check again today.</font>
Finished spading script: excavator.ash

Requesting: https://www.kingdomofloathing.com/api.php?what=status&for=KoLmafia
Retrieved: https://www.kingdomofloathing.com/api.php?what=status&for=KoLmafia
ResponseText has 2722 characters.

Items combed:
Offset 0 out of bounds (BeachComber.ash, line 287)
  at square_at (BeachComber.ash:287)
  at comb_beach (BeachComber.ash:457)
  at comb_random_beach (BeachComber.ash:535)
  at comb_next_beach (BeachComber.ash:566)
  at beach_comb_free (BeachComber.ash:585)
  at beach_comb_free_only (BeachComber.ash:608)
  at main (BeachComber.ash:694)
Finished ASH script: BeachComber.ash
We used the Beach Comb.
-> That left us sitting in choice #1388
KoLmafia started a spading script
The script called an external URL - something on zarqon's server
KoLmafia finished the spading script
BeachComer tries to do this:

Code:
buffer comb_random_beach()
{
    // Wander to a random spot
    buffer page = run_choice( 2 );
    return comb_beach( page );
}
Which should have submitted: choice.php?whichchoice=1388&option=2
But that is not in the DEBUG log.

I conclude that the call/response of that external URL left KoLmafia thining we were no longer in a choice.
That's a bug.

Funny that this was a result of a spading script. :)

I'll look at this later today.
 
I wonder why it did anything with zarqon's server at all! No spading project should have been activated by that choice. Perhaps something happens the first time you run a script that imports zlib?
 
I wonder why it did anything with zarqon's server at all! No spading project should have been activated by that choice. Perhaps something happens the first time you run a script that imports zlib?

Almost certainly. There are a couple of map files that are checked for newer versions and some of the pre-SVN version checking gets run. The debug log shows use_for_items being checked.
 
Any chance you could update this to take advantage of the recent data dump regarding rare locations on the beach? I suppose I could just switch to the other script which was published, but I have already incorporated this one into a few of my own scripts, and would really appreciate it if it was updated.

Of course, it would mean more work for you instead, so I'll understand it if this is not something you want to spend time on.
 
I'm planning on it. I have contributed my "rare square" data to that effort. And I have added the option to VMF to use the other script OR this script. But there is no reason at all I couldn't let you install both scripts and have this one optionally use the data file from the other one.

I could use one of the (more than 800 now!) rare squares to determine which section of the beach to walk to - and if all of the "known" rare squares are already combed - as we expect they will be - choose another "twinkly" square.

And whether or not you are configured to not do that (doing random walks, for example), this script should record/log squares that have a "rare" drop so we can keep building up the public list of "rare" squares, without having to scour session logs, which is what I had to do in order to contribute my "rare" squares to the public data. I would have coded that up a couple years ago, if I'd known that there were three levels of rarity and that specific drops were tied to specific levels.

Long story short, yes. I'm interested and have already been pondering how best to do it. This week, I expect.
 
By the way - combo is a very nice script. I tried looking at it and found the JavaScript incomprehensible, and then I realized the actual source is in typescript, which is compiled into JavaScript. The typescript source is well written, well commented, and easy to understand.

I see that it deterministically shuffles the set of known "rare" tiles - based on your user id - and then goes through them in order, wrapping around when it hits the end, and saving its progress so it can continue the next day. When it visits a section on the beach, it looks for

1) a whale
2) the "rare" tile - if it is uncombed
3) a twinkly square.

As a last resort, it shrugs and combs the already combed tile.

I'd probably prefer

4) rough sand

before giving up, but it doesn't seem like that big a deal.

Which is to say, having studied it, combo does everything I'd have wanted to do - except detect and log new rare tiles discovered in step 3.
 
Thanks for the reply :-) From what you're writing it does sound like combo will cover my needs as well, so I guess I may have a look at it and see if it will be a lot of work incorporating it in my scripts.
 
Back
Top