Regarding my Screenreader extension, @Dannii put a bug in my ear about some standardized way to create startup questions. And the Inquiry extension came out my other ear. (I’m pretty sure that this is nothing like Dannii had in mind, so don’t blame him!)
It lets you define free-form, yes/no, or multiple choice questions (the objects are called “inquiries” in hope of fewer conflicts with existing names). Yes/no inquiries are always single-key input; multiple choice inquiries can be single-key input or line input.
If there are unanswered inquiries, they get asked immediately on startup before other output. You can create questions that are marked answered at the start; if you subsequently mark them as unanswered, they’ll be asked before the next turn (well, provided you don’t mark something unanswered in a rule that occurs after the last scene changing rules check in the turn sequence rules).
Inquiring is an activity, allowing a lot of customization, but with an enormous limit: line-input inquiries get answered as bogus commands as part of the turn sequence. So the activity can handle the whole lifecycle of a key-input inquiry, but it just displays the question for line-input activities, and an After reading the command rule handles input validation and assigning the answer.
It’s probably most easily shown by example. My screenreader extension could be duplicated, essentially with:
Include Inquiry by Zed Lopez.
Lab is a room. "Experiment still not alive."
Screenreader-question is a y/n inquiry. "Are you using a screenreader?"
Interface-value is a kind of value.
Some interface-values are default-interface, screenreader.
The interface is an interface-value that varies.
After inquiring an inquiry (called q) when q is screenreader-question:
if screenreader-question is confirmed, now interface is screenreader.
The open status window after inquiring rule does nothing
when interface is screenreader.
Section Don't ask unless release (not for release)
Screenreader-question is answered.
This example includes a multiple-choice list that’s line-input based first, but becomes key-input based and unanswered if you jump.
Include Inquiry by Zed Lopez.
Lab is a room. "Experiment still not alive."
Name-question is an inquiry. "What is your name?"
Survey is a line-input multiple-choice inquiry.
"What's your favorite beverage?"
The multiple-choice-list of survey is
{ "Tea", "Coffee", "OJ", "water", "zima", "Dr. Pepper", "root beer",
"vanilla cream soda", "beer", "wine" }.
jump-passion is an answered y/n inquiry. "Do you love jumping?"
blank-q is an answered optional inquiry. "Do you have an answer?"
instead of jumping:
now blank-q is unanswered;
now jump-passion is unanswered;
now survey is unanswered;
now survey is key-input;
It’s been tested only a little, and I wouldn’t be surprised if it blew up if you asked particular kinds of inquiries in some particular order. I thought I’d solicit feedback about the interface before I tried to
find and squash more bugs.
When compiled not for release, an inquiries command is included that dumps your inquiries’ current status/values.
–
Edited: I realized I should make a separate finish-inquiring activity for the line-input inquiries so the After reading a command rule itself could be short and simple and the line-input inquiries would be
customizable beyond the asking the question part. So I’ve committed a version 2.
I also made one of the classic mistakes and forgot about ‘g’ and ‘o’ having special-cased meanings wired deeply into the parser. So I now consider it worthwhile to avoid line-input multiple-choice inquiries.