Feature int user_input_int() and string user_input_string()

Hellno

Member
I see it as a good tool to for example tune a script the first time you run it (setting any relevant properties that might not exist yet).

It would also provide a clearer alternative to the current option of having to ask for variables in main() for script that might want them since you can provide a prompt text.
 

Theraze

Active member
Personally, even on the response-example 1, I wouldn't want the script to break automation after 50 minutes to pause and ask me how many adventures I want to spend. If I want to automate farming, I want it to finish. If I want it to define my adventures, I'd want to do that on initial execution, not as an adventure in frustration after my login session times out and causes extra server hits.

Personally I love the ability to type "farm false<enter>login <name><enter>farm false<enter>exit<enter>" and have it farm on both the first and second (or however many more) characters without needing to worry about the script aborting while I'm out at work. Aborting partway through? Bad.
 

zarqon

Well-known member
Heh, I remember that old discussion being rather lively. I also remember that the user_confirm() in ZLib's early forms of check_version() was widely loathed (including by myself -- I was quite happy when I was able to eliminate it).

Removing that user_confirm() from missingManuel was the first thing I did back when I used it, because I dislike the idea of a script bothering you for more information after you already set it about its business. It's like sending someone to the store for milk, and when they get there they call you and ask if you also want bread. No, I would have told you that when I asked you to get milk. I would have said "get milk and also, bread." Your asking implies that I didn't know what I was doing when I only asked you for milk, which I resent. Or they call you at the store to say "How should I pay for the milk? I don't have any money." Why didn't you ask for money before you left?? I sent you to the store to get bread because I don't have time to do all the steps involved myself! Argh!

Emotional objections aside, philosophically I feel that a script is not meant to be a conversation. Normal CLI use of mafia is a series of commands in order, with complete user freedom of choice between them. A script is also a series of commands but with essentially no user freedom of choice. I guess what you're looking for is something in between, a mixture of the script's rigidity and the CLI's user choice, but none of your examples convince me that stopping automation but continuing to limit the users' choice while doing so is useful. All of those examples could be handled by injecting the user's choices into the script via either the initial parameters or script settings. If it's stopping because a choice needs to be made that it forgot to ask for up front, it may as well just totally stop and give full choice back to the user.

Consider installing older versions of Windows -- where the installer would periodically stop to ask questions -- vs. more modern versions that ask all the questions up front. The latter is universally preferred.

Emotional and philosophical objections aside, like Veracity said, I don't oppose the functions being available. In fact, I see some positive uses for them. Hellno made perhaps the most convincing argument in favor of these functions, since presently scripts run with their default settings until those settings are edited. These functions would allow a script to configure itself with user-chosen settings from the get-go, while retaining full automation after those choices were made.
 

Veracity

Developer
Staff member
I'm still thinking "why not". I am also still thinking "I don't care enough to implement this". But I'm looking through pages of old Bug Reports looking for bugs that should be fixed and features that are worthy, and this might be one of the latter.
 

Bale

Minion
This guy said all that I think needs to be said in response to examples of how the feature would be used.

All but the first example sound like scripts that require too much user input for me to ever want to use, and I'm not sure what I think of the first example. I think the only time I would really want prompts after a script starts running is if the alternative is for the script to abort (because reasonable methods of proceeding are reasonably likely to be disliked by people running the script, perhaps), and user_confirm() seems like it would cover that case.

In short, any time this feature would be used, it would be better to make a relay UI script.
 
Top