Feature int user_input_int() and string user_input_string()

PaladinWhite · Oct 25, 2015

AFAIK, currently, the only way to prompt for user input is via boolean user_confirm(). Other types are hard to input.

There are many times when I want to take non-boolean user inputs in order to determine how a script will execute. Currently, I'm using some silly workarounds.

For instance, forcing input as parameters to the main() function, which only works if the script is ready for that input as the very first step:

Code:

void main(int input) {
    int turns_to_spend = input;
    [spend those turns...] // works if I can take input here...

    item thing;
    [...]
    print("You currently have " + item_amount(thing) + " " + thing + ". How many would you like to sell?");
    int number_to_sell = ??? // doesn't work if I need to do something else before taking input...
    [...]
}

or hardcoding values, which cannot be changed during execution:

Code:

int TURNS_TO_SPEND = 50; // edit this value if you want to spend a different number of turns!
[...]

or running user_confirm() in a loop, which is just ridiculous:

Code:

int turns_to_spend;
do {
    turns_to_spend += 1;
} while(!user_confirm("Do you want to spend " + turns_to_spend + " turns?"))
[...]

The ability to input ints would be invaluable. Strings, less so, but there are times when it would come in handy.

(Or maybe there are already ways to do this that I'm missing. Do tell!)

lostcalpolydude · Oct 25, 2015

I feel like there was some discussion years ago about not wanting scripts to constantly prompt people with values. I could be remembering wrong, and user_confirm() already seems to not fit that, so I don't really know how that went.

PaladinWhite · Oct 25, 2015

I'd be interesting in reading that discussion, if anyone remembers where it is.

I guess my take is that, yeah, we don't want people to be constantly pestered. But there's a difference between asking scripters to "do this in a non-annoying way" and not letting scripters do this at all. Other features that could be detrimental to the user, if they're implemented in a crappy way:

Code:

foreach it in inventory {
    cli_execute("smash " + it);
}

if(my_id()) > 2160310) {
    cli_execute("logout");
}

while(black_market_available()) {
    print("I really, really want you to know that you can access the Black Market!");
}

TL;DR every tool can be irritating or detrimental if implemented in a stupid way. Don't hate the tools, hate the... guy who has the tools? The scripter, I guess, is what I mean.

And anyway, if someone goes to the trouble of writing a script that unnecessarily prompts the user, doesn't that deter the author by being overly-difficult, and deter the user by being annoying? I predict that this behavior will be self-limiting.

EDIT: Maybe this is what you're remembering? Apparently that's the thread that spawned boolean user_confirm( string ).

holatuwol seems to have two main objections:

1. an active prompt will pause chat.
To be honest, I'm confused by that objection. Maybe I'm misunderstanding, or maybe Mafia has changed in a significant way since 2007 when this original discussion happened. I use user_confirm() all the time in scripts, and I've not seen it interrupt chat.

... Oh, wait. Does holatuwol mean Mafia's built-in chat function, rather than the relay browser chat? I've never used that, so I can't speak to it. If it's true that prompts would pause the built-in chat, I could see that being potentially irritating to a subset of users. But again, I don't feel like that's a reason to prevent all scripters from using it, even in scripts that are not for public consumption.

2. unspecified "Java focus problems" mean that prompts will sometimes appear behind the main Mafia window.
Again, I'm not sure if I'm misunderstanding, or if something in Mafia has changed, but prompts seem to consistently appear in front of the main window. At least, it's true for me, on Win7 / Java Version 8 update 65 (build 1.8.0_65-b17) / Mafia r16393. So I'm not sure whether this is even an issue. And, again, if even if prompts can sometimes appear behind the main window, I'm not convinced that it's reason enough to restrict optional functionality.

Bale · Oct 25, 2015

lostcalpolydude said:
I feel like there was some discussion years ago about not wanting scripts to constantly prompt people with values. I could be remembering wrong, and user_confirm() already seems to not fit that, so I don't really know how that went.

It was on the old bug tracker that didn't survive the forum upgrade. holatuwol argued that if mafia was able to prompt for more detailed information than yes/no or values at the very beginning of running a script (parameter for main), then it would inevitably be overused by scripters and he didn't want scripts to be often interrupting their processes to request user input.

Personally I believed that the argument was bad because it is essentially saying that scripters are children that cannot be trusted to play properly with their toys. Of course there will be scripters that misuse the tools in the box, but that is true today. The actual limiting factor is that people don't like to use bad scripts.

PaladinWhite · Oct 26, 2015

Bale said:
Personally I believed that the argument was bad because it is essentially saying that scripters are children that cannot be trusted to play properly with their toys. Of course there will be scripters that misuse the tools in the box, but that is true today.

Couldn't have said it better.

fronobulax · Oct 26, 2015

As I imagine implementing this, I ask about headless. If the user is running KoLmafia without a GUI what should happen? The obvious answer is whatever happens now with user_confirm but I'm not sure what that is and, if interactive scripts become common, I'm not sure that is the right answer. (Not saying it is the wrong answer either, just asking).

As for the Java window focus problem, it is real and still exists in 1.7 and 1.8 but every time I have actually seen it and had access to source code it was a programmer error. In my own case I have caused it by using null as the parent window rather than figure out a valid parent or I have used a parent that was not visible or some other state that made having children inappropriate or a couple other things that I am repressing the memory thereof.

PaladinWhite · Oct 26, 2015

fronobulax said:
As I imagine implementing this, I ask about headless. If the user is running KoLmafia without a GUI what should happen? The obvious answer is whatever happens now with user_confirm but I'm not sure what that is and, if interactive scripts become common, I'm not sure that is the right answer. (Not saying it is the wrong answer either, just asking).

I never run Mafia headless, so it'd be interesting to hear from someone who does. "Whatever happens now with user_confirm()" does seem like a good place to start.

That said, two things occur to me.

(1) What portion of the userbase ever runs headless? I can only imagine it's a tiny fraction (although I have no data to support that). If the vast majority does not run headless, then it might be reasonable to implement this even if there's not a good headless solution.

(2) Even if some people do run headless, and we can't come up with a good headless solution, I'm not sure that's a good reason to restrict optional functionality. Mafia hasn't eschewed the option of colored output just because some users are colorblind. If some scripters want to avoid colored output in order to tailor towards colorblind users, that's great, and they have that option, but that doesn't mean other scripters shouldn't be able to use colored output. (I think it's a great idea to minimize popups in Mafia's built-in functionality. But this would be an option for scripters, not something built-in.)

Which is all to say: I think we should try to come up with good headless handling if possible, but if there's not a graceful way to handle it headlessly, I think these functions should still exist.

Crowther · Oct 26, 2015

PaladinWhite said:
Mafia hasn't eschewed the option of colored output just because some users are colorblind.

For some reason this argument and your malicious code argument above both bother me enough to want to never read your posts again. Saying that some other existing feature is no worse than your new feature isn't a justification for implementing your idea. Not in the slightest. I also don't like when people post malicious code. There's no call for that. We can all write such things easily. Anyway, stick to why your feature is important and don't feel you need to defend it to the death just because you brought it up. I'm sure you have some script where you feel this feature is needed. What is that?

Bale · Oct 26, 2015

Crowther said:
I'm sure you have some script where you feel this feature is needed. What is that?

This. I know that for myself, an interesting real-world application is always the most compelling argument.

PaladinWhite · Oct 27, 2015

Crowther said:
For some reason this argument and your malicious code argument above both bother me enough to want to never read your posts again.

wellthatescalatedquickly.gif. What you're hearing as "defending this idea to the death" was intended as "offering a variety of reasons why I think this would be a good idea." I do apologize if I've crossed some invisible line by discussing the idea at offensive length.

It's true that I'm saying that "this feature would be no worse than Feature X that already exists." That's not to say that this new feature or Feature X are either good or bad - I'm simply trying to point out that Mafia's existing codebase does adhere, intentionally or unintentionally, to certain standards, and this feature would fit those existing standards.

In terms of real-life examples, I tried to provide a few (albeit simplified) ones in my original post. Here more:

asking "How many turns do you want to spend doing this thing?" ("After farming up the goal you wanted, you have 165 adventures left. How many would you like to spend meatfarming?")
asking "How much time do you want to spend doing this thing?" ("This script could take a long time to run. Please enter a maximum execution time in minutes, and the task will output partial results if it's not done by then.")
asking "How many times would you like to cast this skill?"
asking "How much MP would you like to spend casting this skill? Or how much would you like to reserve once casting is done?" ("Now's the time in this script where you cast Phat Loot Lyric. You have 500 MP. How much of that MP would you like to spend?")
asking "How many of this item do you want to eat/drink/spleen/buy/sell/smash/move from one location to another/etc?" ("You have 6 hot hi meins. How many would you like to eat?")
asking "How much meat would you like to spend doing this thing? What's the highest price you'd like to pay?" ("You need a worthless trinket. You have 112 meat. How much would you like to spend gumfishing for worthless items?")

These are all questions that I think are often useful to ask during execution, not when a variable is written into a script or first-thing when a script is run. And they're all questions I'd like to be able to ask myself in my own scripts. I leave it to you all to decide whether you'd like to be able to ask them, too.

lostcalpolydude · Oct 27, 2015

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.

So I'm not saying that this shouldn't be added, but I don't feel interested in spending any time on it.

Veracity · Oct 27, 2015

It's probably not hard to provide an ASH interface to additional Java user input methods.

But, with the exception of a very small number of utility scripts - and a similarly small number of relay scripts - I don't use scripts to automate anything. I have an interest in the "correctness" of the ASH language, so I fix bugs there, and I am similarly invested in KoLmafia's ability to automatically learn about items, familiars, effects, whatever when you discover them in the wild, via parsing the descriptions, or rel strings, or whatever, so I also try to keep that functioning well. But anything else, these days, I pretty much only work on to let me be more efficient with things that I personally want to do. Hence my current work on Numberology, for example. If you can pique my interest in something that I won't personally use, because it's an interesting technical problem, or I will learn something while coding it, good for you! Otherwise, I'm leaving it to the other devs.

I have no philosophical or technical objections to letting people write scripts that prompt during execution. If it makes the script author's life more convenient, that's cool. If would-be users find it inconvenient, they have multiple options, from not using the script, to modifying it to their taste, to trying to convince the script author to change it. But I don't see a problem with providing features that have the potential of both making your script less popular to others and more suited to your personal taste.

I'm basically agreeing with lost: I'm not going to argue against this idea, since I will never, ever, encounter it in practice, but I will not be spending my precious time to add it.

Darzil · Oct 27, 2015

I don't use many scripts which have user_confirm. The main one I can think of is Missing Manuel, which I really should alter, as I never want to print the whole list, and always want to print the remaining list, and run it most days.

Scripts that have prompts are usually ones I don't use, ideally any prompt should only be used when the script is called without parameters, and only then to prompt for missing parameters (and frankly, I'd prefer a message that gave the parameters). If more setup is needed, then I prefer a relay script for settings, like slime.ash does.

But if there is a large clamour out there for this, then perhaps it should be done.

If anyone can post me an extra few hours spare time a day I'd then look at it after the changes I'd like to prioritise!

fronobulax · Oct 27, 2015

I certainly could be wrong, but I recall a period of time when hola was actively involved in development and maintaining a working and useful headless environment was important to him. It is not, and was never about, how may people used it. It was just one of those guidelines (like don't make unnecessary server hits, don't implement something in mafia that would be better as a script) that the people doing the work choose to follow. These guidelines do evolve because we were tied to Java 1.4 (or was it 1.5) for quite some time after it was stable because hola wished to support on old Apple hardware/OS combination and the latest Java was not, and never would be, available for that system. We have moved past that.

Tangentially, I recall a couple use cases for headless. One was the situation where a user could not run KoLmafia on their local computer, but they could telnet (or secure and robust equivalent) into a computer that could. But that computer did not provide a GUI across telnet and the usual X Windows tricks were not available/allowed. The second was someone who ran at work and the boss knew the KoL GUI meant they were slacking off but could not tell what was happening at a command line and so assumed work was being done. Finally, back when I thought an Android was something that dreamed of sheep and not an OS, there were folks who were having some success in getting KoLMafia to run on Android by wrapping a headless instance in an Android specific GUI. Clearly that did not work well enough to be released and publicized but it is a use case.

So either we support headless or we have a separate discussion with a possible decision to stop supporting it.

That said, supporting headless is not a big issue. The ash function that pops up the GUI element just has

if (headless) then
pop up gui
else
do something reasonable
end

My question was really interested in "do something reasonable". What is reasonable for ash to do if an interactive script is run in a headless environment? Does it abort? Does it assume some hardcoded value instead of the user input? Is the function defined in such a way that the script writer must provide a default as one of the function's parameters? I can argue for and against any of these but I would hope that any implementation made it clear what was going to happen.

That said, it is not a feature I am likely to use or want. I already have aliases that wrap current scripts which prompt with the values I use 90% of the time. But I am not opposed to it, just not yet convinced that it is something I want to implement.

heeheehee · Oct 27, 2015

While I do run several bots in the cloud via headless Mafia, these bots run solely on my own scripts, so additional user input commands would not affect me.

Crowther · Oct 27, 2015

fronobulax said:
One was the situation where a user could not run KoLmafia on their local computer, but they could telnet (or secure and robust equivalent) into a computer that could.

I don't think I ever posted about it, but I was one such user. I'd ssh into my home computer and run kol entirely by command line. Overdrink didn't exist then. I remember that prompt being an issue of some kind, but it was so many years ago. In case anyone was curious, I was in Antarctica at the time working over a shared geosynchronous satellite link. Most days a cron job fired and I didn't play manually at all.

Bale · Oct 27, 2015

I guess I have to join the chorus of, "I'm not opposed to the feature, but I am not likely to use and I don't think I would want to use it." For my purposes, all relevant issues were solved in a superior way by the advent of relay UI scripts.

Darzil said:
I don't use many scripts which have user_confirm. The main one I can think of is Missing Manuel, which I really should alter, as I never want to print the whole list, and always want to print the remaining list, and run it most days.

Heh. I already made that exact change to my SVN version of missingManuel.

Crowther · Oct 27, 2015

Bale said:
Heh. I already made that exact change to my SVN version of missingManuel.

Same here.

Hellno · Oct 27, 2015

I support this suggestion.

PaladinWhite · Oct 27, 2015

Hellno, is there a particular use you'd imagine for the feature? Some devs have requested use-cases, and I can totally understand how that can be the difference between "an interesting thought" and "worth my time to code up."

Feature int user_input_int() and string user_input_string()

Member

Developer

Member

Minion

Member

Developer

Member

Active member

Minion

Member

Developer

Developer

Developer

Developer

Developer

Active member

Minion

Active member

Member

Member