Proof-of-concept Integer Input

[Catch-22]

I know this has been an age old request from many budding, young scripters: "How can I prompt a user for integer input in the middle of a script?".

Any scripting guru will of course know that you can't.

Or can you?

However, after a script has started, only yes/no can be asked of the user. The problem is that you wish to enter an integer after the script already began.

It was this post specifically which inspired me to write this proof of concept ASH script. I don't recommend anyone using this for their production scripts. I merely wrote it for a bit of fun

Simply run the script from your drop down menu and enjoy the integer input!

I've set the maximum number to 255, but that can be edited in the script if you really wanted to change it.

Spoiler:
It also contains a decimal to binary conversion function, which I'm pretty proud of!

 

[Bale]

LoL! OMG I can't believe you wrote that. Looks like fun.

Incidentally, it is possible to get an integer input by using cli_execute("call integerInputScript.ash") where integerInputScript.ash has an integer as a parameter of main and has the sole purpose of saving that input parameter in a preference which is then checked by the calling script. That is clunky, but it does work. Your method is less practical, but far more fun.

// This is integerInputScript
void main(integer input) {
   set_preference("scriptInput", input);
}

 

[heeheehee]

Several other options: a) "Warmer / cooler", b) "enter the binary representation" (guaranteed to be a pain for the end-user! Bonus points for an unconventional representation of signed integers, like negabinary), c) "Randomly guess the user's number until it's been guessed correctly" (memoize if efficiency is a slight concern), d) "receive input digit-by-digit" (use bisection to make it go faster).

 

[Catch-22]

Several other options: a) "Warmer / cooler", b) "enter the binary representation" (guaranteed to be a pain for the end-user! Bonus points for an unconventional representation of signed integers, like negabinary), c) "Randomly guess the user's number until it's been guessed correctly" (memoize if efficiency is a slight concern), d) "receive input digit-by-digit" (use bisection to make it go faster).

a) I'm not sure how a warmer/cooler thing would work when I guess your number. For example if your number was 72 and I said 72, is that warmer or colder?

b) By answering the yes/no questions in my current implementation, what you're actually doing is entering the binary representation yes is a 1, no is a 0. Also, the current implementation does actually work with negative numbers (negabinary). Although, it'd be easier to simply ask for a signage (Is your number negative? Yes/No) at the beginning or end of the "guessing" sequence.

c) In theory this could go on forever, unless you removed incorrect guesses from the pool of random numbers, in which case I guess the maximum questions this would have to ask you would be max-1, so in my example up to 254 questions! Plus you'd be pretty upset if you accidentally clicked no when your number finally did come up, haha.

d) This could sort of work, if I you wanted to enter a digit let's say 7834, I guess you could enter the binary digit for 7 (0111), then 8 (1000), then 3 (0011), then 4 (0100), but that seems like more work than simply entering the binary number for 7834 in one hit (1111010011010). It also introduces other issues such as making sure jerks don't enter binary digits greater than 9 (such as 1100).

Good thoughts though!

 

[heeheehee]

a) Well, it's definitely warmer than your previous guess. Obviously there would be slight issues if you say guessed 4 then 12 when my number's 8. Of course, this can be avoided.

b) Sign magnitude is generally more convenient for people to think about, even though it's not two's complement (which is easier to implement, since integers in ASH *are* represented via two's complement)

c) Hence the whole "memoize if efficiency is a slight concern". It's like how bogo-sort can either take infinite time in the worst case, or n! if memoized.

d) By this, I meant: "click okay if larger, cancel if smaller/equal" and have the script figure out the input. Or something like that.

...

Yeah, for the most part, I was presenting completely arbitrary and fairly useless implementations for prompting for user input -- there really is no clean way to go about it. Even worse, how to prompt for anything sufficiently complex, say a string?

 

[Catch-22]

Yeah, for the most part, I was presenting completely arbitrary and fairly useless implementations for prompting for user input -- there really is no clean way to go about it. Even worse, how to prompt for anything sufficiently complex, say a string?

Haha, that's already been taken care of. You see, just as 1's and 0's can be interpreted as decimal numbers, so too could they be interpreted as characters

If you had a limited set of answers though, it would be easier to do something like:

if (user_confirm("Are you playing a moxie class?")) {
	your_class = "moxie";
} else if (user_confirm("Are you playing a muscle class?")) {
	your_class = "muscle";
} else {
	your_class = "mysticalty";
}

Edit:

Another method of character input could be as such:

"Is your first letter from A-M?"
Yes
"Is your first letter from A-F?"
Yes
"Is your first letter from A-C?"
Yes
"Is your first letter from A-B?"
No
"Your word is C, is your word finished?"
No
"Is your second letter from A-M?

etc.