Feature - Implemented Allow user input more advanced than "yes or no" in ash scripts

nworbetan

Member
I have a habit of writing scripts that are capable of doing multiple related things, and I'd like to be able to write scripts that are more interactive than simple "yes or no" questions, because to be honest, users tend to be way less enthusiastic about long lists of configuration options than I am. Specifically the questions that I'd like to ask are along the lines of: "Here are 4 viable options, pick your favorite one." and "How many times would you like me to do that option you just picked?" I can imagine that text input (similar to what happens when you give zero arguments to an ash script that is expecting one) would be occasionally useful too, although I don't think I'd use it very often myself.
 

Soluzar

Member
I have a habit of writing scripts that are capable of doing multiple related things, and I'd like to be able to write scripts that are more interactive than simple "yes or no" questions, because to be honest, users tend to be way less enthusiastic about long lists of configuration options than I am. Specifically the questions that I'd like to ask are along the lines of: "Here are 4 viable options, pick your favorite one." and "How many times would you like me to do that option you just picked?" I can imagine that text input (similar to what happens when you give zero arguments to an ash script that is expecting one) would be occasionally useful too, although I don't think I'd use it very often myself.
I know at least one script (autobasement.ash) which takes a number from user input.

Not saying it's a bad request, just maybe you wanna look at what autobasement is doing for a fallback.
 

Winterbay

Active member
I know at least one script (autobasement.ash) which takes a number from user input.

Not saying it's a bad request, just maybe you wanna look at what autobasement is doing for a fallback.

autobasement does this when you call it at the beginning. This works since the number being requested is for the arguments in the main-function. If you want the script to ask for input while running you are limited to yes/no.

There is a proof-of-concept somewhere on these forums for entering binary code via yes/no requests, you could use that :)
 

roippi

Developer
There are java built-ins for a yes/no, yes/no/cancel, etc. Presumably that's why they're already functions, since it's basically a one-liner to code it.

That's not to say that this isn't possible, but you've gotta help us out by fleshing out the idea more. In the OP's two different examples, one presumably is a select-one-and-one-only type of dialog, whereas the second is an arbitrary text input type of dialog. Also, what should be the function's signature? etc. etc.
 

slyz

Developer
A fun proof of concept by Catch-22, even. You can find it here.

ASH's user_confirm() call InputFieldUtilities.confirm(). I'll try to look at InputFieldUtilities to see if anything in there could be used to offer multiple choices, but I am really low on "messing with Mafia" time.

EDIT: if Roippi is on it, you're in safe hands :)
 
Last edited:

roippi

Developer
ASH's user_confirm() call InputFieldUtilities.confirm(). I'll try to look at InputFieldUtilities to see if anything in there could be used to offer multiple choices, but I am really low on "messing with Mafia" time.

Yeah unfortunately I'm 99% sure that it doesn't have a method that helps us here. We'll (I'll? :) ) have to make something from scratch. Or maybe there's something from the jdesktop library that's useful. Hm.
 

nworbetan

Member
There is a proof-of-concept somewhere on these forums for entering binary code via yes/no requests, you could use that :)
A fun proof of concept by Catch-22, even. You can find it [thread=8027]here[\thread].

You know, I might just work with that as a placeholder for the time being. ;)


There are java built-ins for a yes/no, yes/no/cancel, etc. Presumably that's why they're already functions, since it's basically a one-liner to code it.

That's not to say that this isn't possible, but you've gotta help us out by fleshing out the idea more. In the OP's two different examples, one presumably is a select-one-and-one-only type of dialog, whereas the second is an arbitrary text input type of dialog. Also, what should be the function's signature? etc. etc.

Someone asked me for a yes/no/abort option where I was using user_confirm(), so if that's easy I'd get at least some use out of it immediately. I was thinking that a more generalized user_input(string, aggregate) would be more useful though.

My thoughts about the signature are pretty rough still. The string arument could be the message displayed before the choices, and the aggregate argument could enable arbitrarily large and flexible lists of options without needing a ton of overloading. Use the keys as the text displayed for each choice and if the values aren't empty, return them, else return an int indicating which choice was chosen.
 

Rinn

Developer
Well running an ash script that takes in parameters will prompt you for each individual parameter, giving a function to show those prompts (based on object type passed in) would be a start.
 

xKiv

Active member
I thought there was resistance against this, on the basis that ASH scripts are supposed to be able to run mostly unattended [except when it's something superserious, like "do you really want to smash all your stuff now?"]? (and don't you hate it when a long-running program, like an installer, asks you for something every few minutes, dozens of times, instead of asking for all things at once in the beginning?)

Anyway, if this is going to happen, would it be possible to make it so that inputting N things at once doesn't open N sequential windows? (I am picturing something where you pass in a map of key->{ type, label }, and get back key->value, and it just fills in one window with a table of { label, input element }, with maybe configurable set of buttons at the end )
 

nworbetan

Member
I can understand a preference for non-interactive scripts, and this is kind of an attempt to lessen the amount of clicks required to make a simple choice. With user_confirm() as it is, it takes N clicks to say yes to the Nth of a set of options (i.e. click "no" to the first N-1, then "yes"), but if scripters have the option to present all N choices at the same time, it only takes 1 click. So if it's implemented and used responsibly, it can actually help make make things easier and simpler for users.

Of course, if it's used irresponsibly it could be a mess, but hopefully writers and users know how to avoid messes well enough already.
 

Bale

Minion
As long as all input can be given at the start of execution there are few limits. Other than prompting the user in nicely formatted sentences, with spaces between letters and stuff.
 

fronobulax

Developer
Staff member
I'm violently in favor of non-interactive scripts, but I don't see this as a negative, so long as its use is opt-in by the writer.

The pattern I have used over many years, which I think could apply and would not require any mafia changes is the following:

A "doer script" that had no user interaction and gets all of its inputs from a configuration file.
An "editor script" that displays the parameters, allows the user to change them, and does error checking on the parameters.
A "runner script" that calls the editor script and then the doer script.

The automation at all costs user calls the doer script directly and everyone else the runner. For the advanced user, a text editor can take the place of a runner script. This has worked quite well for me so long as the doer script either uses static parameters or is capable of deriving dynamic parameters based upon static user parameters and dynamic run results.

There is a slime tube script that seems to take a similar approach. As I recall, the relay browser script gets parameters and then runs the tube adventures.
 

holatuwol

Developer
In case it's relevant, we avoided it in the past because if you alt-tab away from KoLmafia and a script prompts you for something, when you click back (as opposed to alt-tab back), you will never be able to find the prompt (it will never be given focus) and KoLmafia will not respond to input until you respond to the prompt. Effectively, KoLmafia is dead unless you know the little quirk where you have to alt-tab instead of click.

As such, the limited functionality and loopholes you need to jump through to get it was to make it so you thought *really* hard before you wrote scripts which prompted people for information.
 

Winterbay

Active member
Since we now have user_confirm with a time limit before entering a default value, couldn't the same be defined for this type of function from the get go in order to avoid that?
 

Bale

Minion
Since we now have user_confirm with a time limit before entering a default value, couldn't the same be defined for this type of function from the get go in order to avoid that?

Good point. All input functions could require the time limit, with a maximum of 5 minutes.
 

Theraze

Active member
Maximum of 5 minutes, minimum of 10/20 seconds? Shouldn't allow people to have <5 second default choices... if you're doing that, you should just set it rather than taunting people with slow computers.
 

holatuwol

Developer
Since we now have user_confirm with a time limit before entering a default value, couldn't the same be defined for this type of function from the get go in order to avoid that?
Well, it wouldn't make the alt-tab problem go away, but at least the UI will be responsive after some time. If the current developers are comfortable with that, then the original concern is unnecessary. :)
 

nworbetan

Member
Are there specific combinations of OS + Java that make that problem happen? I can click either the task bar or the main mafia window, and the pop-up user_confirm window gets focus either way (using Java 1.6.0_37 in Fedora). I currently have the same problem you just described in the newest version of Gimp though, so I can understand why preventing that is a thing worth doing.
 

gausie

D̰͕̝͚̤̥̙̐̇̑͗̒e͍͔͎͈͔ͥ̉̔̅́̈l̠̪̜͓̲ͧ̍̈́͛v̻̾ͤe͗̃ͥ̐̊ͬp̔͒ͪ
Staff member
Addressed in r20797 with the following caveat

There are three functions currently:
* `string user_prompt(string message)`
* `string user_prompt(string message, int timeoutInMillis, string defaultValue)`
* `string user_prompt(string message, aggregate options)`
Note two things:
1. There is not currently a timeout-able option select function. It's harder to do so I've left it for now
2. Whatever type of aggregate you pass as options you will get a string in return. This could be changed in the future
 
Top