Sots Parcel.ash script request

Sorry it's been so long, I have limited time and recruiting toddlers is sucking a lot of it down. Bubblin' caldera, DoD, and Pirate's cove are pretty sucktastic as well. I'd be super happy if I could eliminate bubblin' caldera and sonofa beach though. Hopefully the time gods will be kind to us ;)
 
Well I got distracted with a divide by zero issue and fix but I could and should refocus.

So I don't have to reread everything....

I will add a list of locations. I need to experiment with how a user can add or remove items in the list. It would just be a setting but for my own edification I want to understand how much of a pain adding and deleting will be using just the KoLmafia "tools".

Given the list of locations - if the parcel is in a location on the list then the script will not try and get the parcel. But my question is whether that is a once a day check or always? If it is once a day then the list can be used for locations that require special prep. Run the script, it stops. Do the prep, run it again and it gets the parcel.

The choice depends upon how often there will be locations where you want to do some prep before you visit them. If that never happens then the script should never go to forbidden locations and the user will have to change settings if there is ever an exception. That probably makes the most sense since a script that gets the parcel location and does prep before calling this one is conceptually easy. But if you are interested in doing prep and will do so manually now then stop once is the right answer.

But since the choice is implemented by the name of a preference I can go deal with the arrays first :-)
 
I would much rather do 0 prep and just forget about it for the day. Bubblin' caldera wastes your hp/mp, and the others are just high non-com areas. Anything I can do to avoid fiddling means more real world time in my day. I could only check back right now because one of my accounts apparently got the laggiest KoL server on the planet, and is currently running at least 4 times slower than normal. It's been an hour already :cry:
I say that to say: if you don't see me for a while and you have something new to test, kmail me and I'll get on it!
 
Attached implements a "don't go there" feature.

The attached file and vprops.ash (referenced upthread) need to be in your scripts directory.

The noGo list is a preference that is a list of location names delimited by a "|". The code will make sure each entry is a valid location although I didn't spend a lot of time making error cases and checking.

The preference is SOT.noGo. The cleanest way to set it is at the gCLI, for example

set SOT.noGO=Sonofa Beach | The Bubblin' Caldera

You can also edit the preferences file directly and you can make it global for all characters by editing the script (ask).

If the parcel is in a noGo location then the script won't try and go there.

Lightly tested.
 

Attachments

12 iterations without a hitch so far, 6 to go, but I know I won't have time to post later. Haven't run into a no-go zone yet though.

ETA: Good thing this happened now, just got sent to Bubblin' Caldera :( And I double checked to make sure I set the preference.
 
12 iterations without a hitch so far, 6 to go, but I know I won't have time to post later. Haven't run into a no-go zone yet though.

ETA: Good thing this happened now, just got sent to Bubblin' Caldera :( And I double checked to make sure I set the preference.

The value in the preference must be an exact match. The location is "The Bubblin' Caldera".

The script prints out all of the valid locations in noGo. If you can confirm it printed "The Bubblin' Caldera" then that is definitely something I need to fix. If it printed out " Bubblin' Caldera" then the noGo locations are not being validated as I expect but if it prints neither then whatever you typed when setting the preference was not a valid location.

If you want to deal with making the change every time I update the script you could replace the line

location_set noGo = define_property("SOT.noGo", "location", "none", "set", "|");

with

location_set noGo = define_property("SOT.noGo", "location", "Sonofa Beach | The Bubblin' Caldera", "set", "|");

in Sot.ash.
 
I had unexpected free time!

This is what I entered into the gCLI:
set SOT.noGO=Sonofa Beach | The Bubblin' Caldera | The Dungeons of Doom | The Haiku Dungeon | The Obligatory Pirate's Cove
and it did print what I entered, I can do it again tomorrow for copypasta goodness if you need me to.
 
I had unexpected free time!

This is what I entered into the gCLI:
set SOT.noGO=Sonofa Beach | The Bubblin' Caldera | The Dungeons of Doom | The Haiku Dungeon | The Obligatory Pirate's Cove
and it did print what I entered, I can do it again tomorrow for copypasta goodness if you need me to.

I need to ponder then. Stand by.
 
I may have something. Stand by and in the meantime watch carefully or just sacrifice a few turns "for Science!".
 
Try this. Depending upon how you set up the noGo list you may have to set it up again.

I print out the list in the beginning and I print out where the parcel is. If the complete list is not printed then there is something wrong in how noGo is set. I print out the parcel location just in case the canonical name of a location is not what KoL provided. The new, non-debugging piece is I normalize the location before I compare it to the noGo list which has also been normalized. That should eliminate some possibilities.

But I am pretty much stuck. I can't reproduce an issue in a test script so I don't really know whether this a code or data problem. At least with the verbosity if have something to work with if it happens again.
 

Attachments

Heh, I think Magus Prime was right. I *just* got the Haiku Dungeon, and the script handily ignored it and carried on. Sorry I didn't have a hiccup sooner to save you some effort. I only have two accounts left for the day, but I'll download the update to run with those.

ETA: Huh. So, this is odd, they both got Infernal rackets backstage. Identical locations within a group is unusual, at least for me. I'll report back if I run into any hiccups, but these last two have gone smoothly.
 
Last edited:
Heh, I think Magus Prime was right. I *just* got the Haiku Dungeon, and the script handily ignored it and carried on. Sorry I didn't have a hiccup sooner to save you some effort. I only have two accounts left for the day, but I'll download the update to run with those.

ETA: Huh. So, this is odd, they both got Infernal rackets backstage. Identical locations within a group is unusual, at least for me. I'll report back if I run into any hiccups, but these last two have gone smoothly.

I have only one character with a speakeasy so cannot speak to how locations are selected. I do think there are a couple of times that I got location A on one day and location B the next which suggests some kind of determinism. With time, motivation, the latest version and session logs we could start gathering data.

Glad the script seems to be behaving since I am out of ideas if it isn't.
 
I have most everything deselected on the sessions log page, what would you need me to turn on for that? Also, it's not important, just out of the ordinary in my experience so far.

It's still cranking up the MCD, which is really irrelevant at this level, but will it do that upon ascension? I prefer fun to balls to the wall speed, so I rarely bother with the MCD at all. Even if it does, I'm sure it won't be an issue, it's just weird that it's doing it at all.
 
The script logs where the parcel was left in the session logs and I don't think there is any way to disable that. So look could look for something like

Talking to the Milky-Eyed Sot
> Looking for parcel in A-Boo Peak.

extract the name, associate it with the name of the character and the date of the session and you could start building a database . Then someone who wanted could look for patterns. Doing extraction and association would probably be easiest using scripting tools besides ash or JavaScript. Other than curiosity there probably isn't much point since it is not clear what a player might do today if there were an accourage prediction about where the parcel would be tomorrow.

Not sure what you mean about the MCD. Sot.ash doesn't do anything so if the MCD is changing it is either some other script you are running or a side effect of verifying an adventure location in which case there is an opportunity to verify that the side effect is actually intended.
 
Back
Top