Feature - Implemented Scriptable Choice Adventures

I'm not sure how this would be implimented, or if its even particularily feasible, but i'd love to be able to have an option in some/all of the choice adventures to hand off the decision to a script.

For example, with the new clan basement, the choice options are great, but i'd like to be able to make the decision at the point where the adventure occurs/

EG: attic options would be:

Show in browser
staff guides
ghost traps
mass kill werewolves
other exising options
consult choice.ash

choice.ash could then decide which choice to make based on whether you have chainsaws, silver bullets etc.

I guess what i'm asking for is a customchoice script option a bit like customcombat.

Failing that, I think a run_choice(int) command in ash, (which may be part of the above feature) would be useful, similar to run_combat (which would essentialy be a wrapper to visit_url("choice.php?pwd&whichchoice=x&option=y");

which might be used something like:

exactly what i was meaning in my post on the other thread. wish i had seen yours before i posted. it would also be useful in the spooky forest choice adventure, ie: if i dont have a sapling get it, else if i dont have a map get it, else if i dont have a fertilizer, get it, etc...

just wanted to add that because i think the functionality is good even looking beyond the fact that haunted house is limited time content.

The current workarounds involve either betweenBattleScripts (or mood scripts when you are adventuring via the Relay browser), or simply using visit_url() when you are scripting your adventuring.

Current workaround needs to be the visit_url, because in the case of more complicated choice adventures like the Spooky Forest, bBS only helps if there's only a single choice...

Hijacking this old thread because otherwise I'd have to merge my feature request here. Another discussion spawned this...

Feature Request for an ash function that can run choices.

• string run_choice( string url, int opt )
  Visits url and follows the indicated option number. If opt is -1 then it will continue to goal.
  It returns the final page load as a string, as visit_url() does.
  
  
• string run_choice( int opt )
  As the first, but assumes that the character is already in a choice adventure.
  Returns an empty string if the character was not in a choice adventure.

The reason that the first version of run_choice() is activated by visiting a url rather than adventuring in a location is because choices are not exclusively the result of adventuring. A large number of items (like the grimstone mask or hedge clippers) will trigger choice adventures that may, or may not, take a turn. Equipping the plastic vampire fangs provides a place.php location that is not an official KoLmafia location. That's a lot of possibilites to cover so visiting a url seems to be the best choice. If the scripter wants to use an adventuring location he always has the option of to_url(location).

The return value of run_choice() is particularly valuable since some choice adventures can change their options (eg. The Hidden Heart of the Hidden Temple) and this way a script can parse the return string to decide how to handle the next step using the second verison of run_choice().

I think I have string run_choice( int option ) working locally in a reasonable manner.

This script will pick up your own black heart if you are wearing plastic vampire fangs (and I set choiceAdventure546 to 0 first). Unlike the CLI command, this does not try to continue automation after sending that choice, since a script using this probably wants to parse the page and pick choices based on that each time (and automation would likely fail and abort the script). You can use run_choice(-1) to automate, exactly the same as choice-goal in the CLI. The main downside I see is that there's no validation that a valid option was picked (because sending the selected option is the same server hit as actually loading choice.php just to check if it's valid), so this is a chance for a poorly-written script to get into an infinite loop potentially.

I also have run_turn() written, which is treated as run_combat() or run_choice(-1) as appropriate. I'm not set on that name...

I don't think string run_choice( string url, int opt ) is needed, since many places where mafia won't support a simple option are multi-option adventures anyway, and leading with a visit_url() is straightforward enough.

lostcalpolydude said:

I don't think string run_choice( string url, int opt ) is needed, since many places where mafia won't support a simple option are multi-option adventures anyway, and leading with a visit_url() is straightforward enough.

Click to expand...

Hidden Heart of the Hidden Temple is why I'd like it to return the page load.

How is that not covered by visit_url()? Letting a script use 1 line instead of 2 for including a plain URL doesn't seem much different, and leading with visit_url() means you can parse the page before sending the first choice option.

Using visit_url() to start it will take me to Fitting In. run_choice(2) then takes me to Hidden Heart of the Hidden Temple, but I don't know which version of the temple it is unless I check the page load from run_choice(2). If I had previously adventured there (once I had a problem because I'd tried to do it when I only had 2 adventures and had to return later), then it would not be the default.

That's why run_choice(2) returns a buffer (I said string before, but I have it coded as a buffer, which matches run_combat() ), so you can parse the page to figure that out. That's why my example script up there has everything in print() statements, it shows that actually working.

Oh. Yeah, I can work with a visit_url() lead off I guess.

Consider me satisfied with the intended implementation.

Added those in 15235.