Grouped Messages As Dialogue

version 1 by Ron Newcomb

  • Home page
  • Beginning
  • Next

  • Documentation

    Chapter : Errors As Dialogue

    Section : Purpose

    It is said there are at least four people present in every interactive fiction: the human player, his character the protagonist, the author as narrator, and the computer as the parser. This extension's aim is to thin the crowd. Although extensions such as David Fisher's excellent "Default Messages" and "Custom Library Messages" -- on which this is heavily based -- allow changing Inform's built-in messages and errors, they cannot easily change them during play. Hence, cloaking parser errors and action acknowledgements in an NPC's responses is generally limited to NPCs who accompany the player at all times. Due to this limitation, it came to be known that such error messages are a fine way to characterize the PC. But now, they can characterize NPCs as well.

    This extension allows two things. One, the responses for all error messages and action acknowledgements can be changed from one character or narrative voice to another at the flick of a switch. There is no processing overhead for this switch, and it is possible that even the switch itself can be automated. Two, the act of printing a particular message is now a rule rather than a static string, so a great deal of declarative processing -- Inform 7's strength -- can be brought to bear. Want to have a character comment on seeing the player make an entire series of actions and attempts? No problem. Hint system need some data to analyze? Easy. Need the primary antagonist to learn by watching the player's trials and tribulations? Here's some hooks.

    And here's how it works.

    Section : Basic Usage

    Every set of responses is wrapped in a rulebook, with a default value of success, and assigned to a character's "observations" property:
        Alice's responses are a rulebook. Alice's responses have default success. The observations of Alice are Alice's responses rulebook.

    And each rule within recognizes and responds, either to a particular error, or to a group of them:
        *:Rule for Alice's responses when asking which do you mean:
            say "'Sure! Would you like [a prepared list delimited in disjunctive style]?'".
        Rule for Alice's responses when printing a parser error:
            if the parser error is only understood as far as, say "'I can [parser-understood words], but I'm not sure about [parser-confusing words],' she says.";
            otherwise continue the action.
        Rule for Alice's responses when the message of the game error is LibMsg <report player taking> and when the noun is the black puppy:
            say "'Smokey bites,' she warns.".
        Rule for Alice's responses when the message of the game error is LibMsg <report player taking>:
            say "Alice hands you [the noun]. 'Need anything else?'[line break]".

    The variable "observer" is the person who will be commenting on the action. We could do worse than keeping this in sync with "the current interlocutor" from Eric Eve's conversation extensions. We must be sure to initialize it to someone when play begins.
        The observer is Alice.

    If a character's response rules fail, then this extension will consult "the default errors rulebook". Rules we put into here are used for everyone if a particular character doesn't have anything to say for a particular situation. And if the default errors rulebook fails, the standard Inform 6 messages are used. So, we can put rules in the default errors rulebook which will override Inform's defaults but censors itself in lieu of a character's specific response.
        Rule for default errors when game error is LibMsg <empty line>:
            say "Dear reader, this is the 'command prompt'. Here is when and where you type in what you would like your character to do.".

    (NOTE: We have two known limitations. One, it seems that rules depending on Activities need to be listed before any "when the message of the game error is" rules. Two, we must never set Game Error directly; always use one of the Observe phrases shown below.)

    Section : Grouping Messages Together

    The various error and acknowledgement messages are grouped together so multiple situations can be overridden together, as in:
        Rule for Alice's error when game error is failing not out of world:
            say "'Let me know if I can help you with any of that,' says Alice.".

    The groups are declared as a "can be" property on the library-message kind. (The Game Error is an object of that kind.) The pre-existing ones are:

        * out of world - A character would have to break the fourth wall to remark on one of these.
        * action acknowledgement - "Taken" and other such successful actions.
        * failing - an action stopped, usually because of some sort of "cannot" rule.
        * futile - searching in the dark, doing something already done, emptying something into itself, etc. Not all actions that fail are futile. Attempting to open a locked door would fail, but the attempt wasn't futile. How are we to know a door's locked until we try it?
        * re-attempting - doing something already done is always a futile activity, but not all futile activies involve re-doing something.
        * blocked - blocked actions. See the Actions index for the actions which do nothing unless rules intervene.
        * darkness-involving - self-explanatory.
        * parser-erroring - the built-in parser errors.
        * parser-modal - the parser is in a special mode, such as waiting for a disambig. answer, a Yes/No answer, a menu selection, a SPACE to continue, etc.
        * answer-awaiting - a subset of parser-modal: a disambig answer, yes/no, or menu selection.
        * physically-vigorous - Climbing, jumping, attacking, etc. Indiana-Jones kind of stuff.
        * bodily-senses - taste, listen, sleep, etc.
        * civilized - giving, showing, asking, saying, telling, kissing, hugging, and all conversation. Sadly, a smaller list than Indiana's.
        * conversational - a subset of civilized, and including the answer-awaiting parser problems.
        * involving-nothing - self-explanatory, and probably futile, too.

    We can freely add and modify groups as well. See chapter two, below.

    Section : Yes and No

    We can override the <block saying yes> and <block saying no> errors same as any other, but we now have some additional functionality for deciding the effects of these two words for any particular usage. The phrases used to point these answers to a rule (or rulebook) are:

        Yes is (a rule);
        No is (a rule);
        Yes is (a rule) and ignored;
        No is (a rule) and ignored;

    If our prose ever asks a yes/no question of our player, we can point the answers to the appropriate effects in this way. The "and ignored" bit means it will not terminate an existing Which question (see section below: NPCs cause parser errors on purpose). When we're done (either because one was called, or our player chose some third option), we can reset them so that future use will once again trigger their respective <block> messages.

        reset yes and no;

    Section : Other Handy Phrases to be Found in Error Messages

    We can invoke a message manually, and frequently need to for home-made messages. We use one of these phrases, knowing that the Observer will be used if no character is specified. There are also equivalent say-phrase versions of these:
        Bob observes LibMsg <ok>;
        observe LibMsg <ok>;
        Alice observes the game error;
        observe the game error;
        if LibMsg <ok> is observed, stop the action; otherwise say "LibMsg <ok> not handled.".

    We can have one character defer to another for particular messages, or say something else if they "cannot defer to" because the other character is not in the location:
        Rule for Bob's error when message of game error is LibMsg <report player taking> and when the noun is the black puppy:
         say "'[']Ey Alice! What'dya say [']bout Smokey?'[line break]";
         if cannot defer to Alice, say "'Ah she can't hear me.'".

    There are also say-phrase and non-conditional versions of deferring:
        defer to Alice;

    The Which Do You Mean activity allows the say phrase "prepared list delimited in ... style" from Emily Short's Complex Listing extension. This extension is automatically included.

    The Understand As Far As parser error defines two say phrases: "parser-understood words", as the player's command that it can understand, and "parser-confusing words", as the rest that it didn't.

    Finally, a few miscellaneous phrases, which are identical to their Default Message extension counterparts. "The main object" is frequently the noun, actor, or direction in question. Also look for "the number understood". "What's on the object" is a say phrase for listing the contents of the main object. "What's inside the object part 2" is similar. And "What's inside the object part 1" is a say phrase for the subject of a sentence that will describe the contents of the main object.

    Chapter : New Ways To Respond

    Section : Adding New Actions and Responses

    New actions and new parser errors can always be created in a work, and it's easy to hook them into this system. First, give the new situation a name, by adding it to this single-column table:
        Table of library messages (continued)
        Message Id
        LibMsg <my first hook>

    New actions in particular will require the Observe phrases (from the Handy Messages section above) in their first report rule. When it returns true, then someone (or something), somewhere, just commented on our new action, so the rest of our action's report rules can probably be skipped.
        The first report an actor innovating:
            if LibMsg <my first hook> is observed, stop the action.

    And now we can write the rule to do whatever magic for each character. Of course, putting a rule into the Default Errors rulebook is probably a good idea as well, for testing purposes if nothing else. Obviously, there is not an Inform 6 built-in message for our new situation.
        Rule for Alice's responses when game error is LibMsg <my first hook>:
            say "'Oh! The most curious thought just struck me,' says Alice.";
            fetch brilliant idea for Alice;
            consider the scene changing rules.

        Rule for default errors when message of game error is LibMsg <my first hook>:
            say "[message of game error] STILL UNWRITTEN FOR [observer]!".

    Many times, what is entered at the command prompt will produce absolutely no change in the game, but when spoken to a character, should still invoke a tailored response. With the appropriate rules in each character's observations errorbook, here is an example of how to handle such a thing succintly:
        Table of library messages (continued)
        Message Id
        LibMsg <ok>
        LibMsg <please>
        LibMsg <thanks>

        Understand "ok" or "okay" as a mistake ("[observe LibMsg <ok>]").
        Understand "please" as a mistake ("[observe LibMsg <please>]").
        Understand "thanks" or "thank you" as a mistake ("[observe LibMsg <thanks>]").
        Rule for default errors when the message of the game error is LibMsg <ok>: say "You get a nod in reply.".
        Rule for default errors when the message of the game error is LibMsg <please>: say "'But of course.'".
        Rule for default errors when the message of the game error is LibMsg <thanks>: say "'Your welcome.'".

    Even if one particular character is a stickler on manners, how she personally processes them need not complicate the work in general.

    Finally, and optionally, we can put our new messages into the pre-existing groups.
        A categorizing errors rule for when message of game error is LibMsg <ok>: now game error is conversational; now game error is civilized.
        A categorizing errors rule for when message of game error is LibMsg <please>: now game error is conversational; now game error is civilized.
        A categorizing errors rule for when message of game error is LibMsg <thanks>: now game error is conversational; now game error is civilized.

    Section : Adding Groups

    When an error occurs, the categorizing errors rulebook is called, which has one error per rule, and sets the appropriate categories for each. We can add our new error messages to this rulebook, and we can also create new categories if we like.
    New groups can be created thusly:
        A library-message can be something-special.
        First categorizing errors rule (this is the reset my new error categories rule):
            now game error is not something-special;
    We categorize new messages same way we categorize them into existing groups:
        A categorizing errors rule for when message of game error is LibMsg <ok>: now game error is conversational; now game error is civilized; now game error is not something-special.
        A categorizing errors rule for when message of game error is LibMsg <please>: now game error is conversational; now game error is civilized; now game error is not something-special.
        A categorizing errors rule for when message of game error is LibMsg <thanks>: now game error is conversational; now game error is civilized; now game error is not something-special.

    We categorize existing error messages by adding a second rule that applies to them. We can also remove them from their pre-existing categories:
         A categorizing errors rule for when message of game error is LibMsg <Inventory no possessions>: now game error is something-special; now game error is not involving-nothing.

    Try it out:
        A default errors rule when the game error is involving-nothing: say "(There's a whole lot of nothing around here.)".
        A default errors rule when the game error is something-special: say "Well isn't that special.".
        Test me with " i / please / ok / thank you ".

    Section : NPCs Cause Parser Errors to Ask Questions

    Conversation frequently involves people taking turns speaking, and ending one's speech with a question is an obvious way to flag the listener of her turn to speak. It's also a subtle way to guide a person toward or away from certain subjects. In this way, the below Ask routines are handy within the NPCs' errorbooks as a way to guide the player away from the less simulated portions of the game, and toward the more interesting portions.

    So while we're overriding the response to Which Do You Mean, consider this: "which" is the most basic question word of English. All others are defined in terms of it: "who" asks which person, "what" asks which noun, "how much" asks which number and unit, "how many" asks which whole number, etc. The Which Do You Mean activity is actually a very general question-asking routine, and nicely sets up the parser to understand a direct answer, or ignore the question entirely if our player wishes, without any additional work. This extension provides an "ask" phrase to our NPCs which causes this particular parser error on purpose. The main variations are:

        (a person) ask/asks (some text);
        (a person) ask/asks (some text) expecting/including (a description);
        (a person) ask/asks (some text) excluding/except (a description);
        (a person) ask/asks (some text) expecting/including (a description) excluding/except (a description);

    The person that begins each is optional. If dropped, the observer is used, which is handy since this phrase will most likely be used within someone's observations errorbook. Also, these can be used either as statements or as conditions in an if statement, because it is possible the descriptions we feed it may result in no objects. If no objects are the case, the quotation fed to the routine is not printed, and Yes and No are reset. Here's the relevant excerpt from the examples section below:

        Rule for Bob's error when game error is LibMsg <report player taking>:
            say "'[']ere ya go.' Bob hands you [the noun]. ";
            if ask "'Can ya think of anything ya might also need?'" expecting anything except things carried by the player begin;
                Yes is the Whazzat rule and ignored;
                No is the Said No To Need Anything Else rule;
                now the verb word is "take";
            end if;
            say line break.

    This particular bit of code asks for any thing in the shop, will say whatever's in the Whazzat rule but otherwise ignore a Yes, and No will terminate the question with saying whatever is in the Said No To Need Anything rule. We currently must set the verb word to the action Bob is essentially asking us to do: take another object from his store shelves, in this example. However, it can be set to other verbs; whichever is appropriate for what the NPC's prose is asking about.

    Note that this code will not print whatever Which Do You Mean phrase Bob always uses -- the quotation passed to Ask is the last thing printed. Moreover, Which Do You Mean will not activate when the player answers -- by then the question is already answered. We should merely know that that activity is happening behind the scenes (and upon a property called "relevant/irrelevant") in case a particular project's own code needs to engage the activity further.

    Section : Multiple Narrative Tones, or, Who Gets To Respond

    To recap, the rulebook assigned to a character's observations property takes precedence, and if it doesn't succeed in producing something, the default errors rulebook is consulted for a basic but still game-specific handling, and if -it- fails, the built-in Inform response is used.

    Unless we change this.

    "The observer finder rulebook" decides this heirarchy. It is a simple book of only two rules, "Consult Character's Errorbook" and "Consult Default Errorbook", in that order. ("Consult Default Errorbook" is the Last rule of the book.) Unlike a character's observations errorbook which runs at most one rule, the observer finder rulebook runs all its rules until something succeeds. Adding rules here is a good way for the extension to consider our newly-written response packages that aren't tied to a particular character. For example, we could write several author-as-narrator packages, each in a different tone. First, we modify the observer finder rules:
        Narrative tone is a rulebook that varies.

        This is the Consult Narrative Tone rule:
            if using errors as dialogue debugging option, say "// 'Observer Finder' consults tone [the narrative tone].";
            abide by the narrative tone.
        The Consult Narrative Tone rule is listed first in the observer finder rulebook.

    Then we start creating our packages:
        Silly is a rulebook. Silly has default success.
        Rule for silly when game error is LibMsg <report player taking>: say "Yoink!".

    Finally assign one of those packages its task:
        When play begins: now narrative tone is silly;

    And if we'd like to see our modified observer finder rulebook in action, we can include this statement in our project:
        Use Grouped Messages As Dialogue debugging.

    Section : A Changing of the Guard

    The observer finder rulebook is not called directly by the low-level processing code. Rather, a simple variable, the rulebook-that-varies called "the current errorbook", is considered. Pointing this to a rulebook to our own devising is trivial, but know that we will lose automatic calling of the default errors rulebook by doing so. Still, it may useful to use the observer finder rulebook's heirarchy in only portions of the game, and we can always set the current errorbook to the observer finder or default errors rulebooks at any time.

    Chapter : Credits

    This extension would not be possible without the technical assistance and code of David Fisher and Emily Short. I thank them for their incredibly useful extensions and bits of code. Their specific pieces are highlighted within this extension's source, in the section headers. Also thanks to JDC and ??? from the raif newsgroup for a particular coding trick which made NPC Asks possible.

    Chapter : Reference List of Supported Errors and Messages

    These are identical to David Fisher's extensions, with a few exceptions. Any tag that included the conjunctions "and" or "or" was renamed to exclude such conjunctions -- they use a hyphen in place of the conjunction. A couple of exceptional cases in his code were refactored to work within the normal framework. And LibMsg <no error> was added as a base case.

    Most block and report messages are together at the bottom of the list.

        LibMsg <no error> - Base Case. If this happens, it's a parser error or activity avoiding normal processing, or normal processing directly calling an errorbook.

    Section : Fourth Wall Messages - out-of-world action acknowledgements

    Fourth Wall messages include parser errors, game status, and other actions and acknowledgements that happen out-of-world. If a character comments on them, he or she is breaking the fourth wall.

    Regarding Looking
        LibMsg <brief look mode> - The BRIEF command
        LibMsg <superbrief look mode> - The SUPERBRIEF command
        LibMsg <verbose look mode> - The VERBOSE command
        LibMsg <top line what on> - These three appear next to the bold-printed room name.
        LibMsg <top line what in>
        LibMsg <top line what as>
        LibMsg <yes-no prompt> - "Please answer yes or no."
        LibMsg <Pronouns initial text> - These three are for the PRONOUNS command: "At the moment, "
        LibMsg <Pronouns -means- text> - " means "
        LibMsg <Pronouns -unset- text> - " is unset "
        LibMsg <you have died>
        LibMsg <you have won>
        LibMsg <confirm Quit>
        LibMsg <confirm Restart>
        LibMsg <Restart failed>
        LibMsg <Restore failed>
        LibMsg <Restore succeeded>
        LibMsg <Save failed>
        LibMsg <Save succeeded>
        LibMsg <Verify succeeded>
        LibMsg <Verify failed>
        LibMsg <transcript already on>
        LibMsg <transcript already off>
        LibMsg <start of transcript>
        LibMsg <end of transcript>
        LibMsg <transcript failed>
        LibMsg <end transcript failed>
        LibMsg <Score command>
        LibMsg <score changed>
        LibMsg <score notification turned on> - The NOTIFY ON command
        LibMsg <score notification turned off> - The NOTIFY OFF command
        LibMsg <Full Score initial text>
        LibMsg <Full Score items>
        LibMsg <Full Score places>
        LibMsg <Full Score total>
        LibMsg <page prompt> - "[bracket]Please press SPACE.[close bracket]"
        LibMsg <menu prompt> - "Type a number from 1 to N, 0 to redisplay or press ENTER."
        LibMsg <restrict answer> - "Please give one of the answers above."
        LibMsg <undo succeeded>
        LibMsg <undo failed>
        LibMsg <undo not provided>
        LibMsg <cannot undo nothing>
        LibMsg <cannot undo twice in a row>
        LibMsg <oops failed> - Abbreviation for OOPS is O
        LibMsg <oops too many arguments>
        LibMsg <oops no arguments>
        LibMsg <again usage> - Abbreviation for AGAIN is G
        LibMsg <cannot do again>
        LibMsg <command cut short> - An memory buffer overrun error, usually from the player's command being very long, results in this error: "(Since something dramatic has happened, your list of commands has been cut short.)"
        LibMsg <say things within>
        LibMsg <say things also within>
        LibMsg <say things on>

    Section : Fourth Wall Messages - parser errors

    Most of these are already expressed through Inform 7, but we may like to keep all of a character's messages in the same place, and deal with them equally.
        LibMsg <noun out of context> - parser error is did not make sense in this context: "That noun did not make sense in this context."
        LibMsg <unimportant object> - parser error is not something you need to refer to: "That's not something you need to refer to in the course of this game." (Scenery objects)
        LibMsg <empty line> - parser error is i beg your pardon: "I beg your pardon?"
        LibMsg <command not understood> - parser error is didn't understand: "I didn't understand that sentence."
        LibMsg <command partly understood> - parser error is only understood as far as: "I only understood you as far as wanting to [parser-understood words]"
        LibMsg <command badly ended> - parser error is didn't understand the way that finished: "I didn't understand the way that finished."
        LibMsg <command incomplete> - parser error is said too little: "You seem to have said too little!"
        LibMsg <number not understood> - parser error is didn't understand that number: "I didn't understand that number."
        LibMsg <unknown object> - parser error is can't see any such thing: "You can't see any such thing."
        LibMsg <object not held> - parser error is aren't holding that: "You aren't holding that!"
        LibMsg <unknown verb> - parser error is not a verb i recognise: "That's not a verb I recogni[s/z]e."
        LibMsg <verb cannot have inanimate object> - parser error is can only do that to something animate: "You can only do that to something animate."
        LibMsg <verb cannot have multiple objects> - parser error is can't use multiple objects: "You can't use multiple objects with that verb."
        LibMsg <too many multiple objects> - parser error is can only use multiple objects: "You can only use multiple objects once on a line."
        LibMsg <not that many available> - parser error is not enough of those available: "None/Only [the number understood] of those is/are available."
        LibMsg <no objects available> - parser error is not enough of those available: "There are none at all available!"
        LibMsg <zero multiple objects> - parser error is nothing to do: "Nothing to do!"
        LibMsg <excepted object not included anyway> - parser error is excepted something not included: "You excepted something not included anyway!"
        LibMsg <pronoun not set> - parser error is not sure what it refers to: "I'm not sure what [the pronoun understood] refers to."
        LibMsg <pronoun absent> - parser error is can't see it at the moment: "You can't see [the pronoun understood] ([the main object]) at the moment."
        LibMsg <cannot begin at comma>
        LibMsg <extra words before comma>
        LibMsg <comment recorded>
        LibMsg <comment unrecorded>
        LibMsg <period newline>
        LibMsg <question newline>

    Section : Quizzical Characters

    As in the above documentation, our characters may cause parser errors on purpose, so that they may understand the context of their own questions.
        LibMsg <who disambiguation>
        LibMsg <which disambiguation>
        LibMsg <whom disambiguation>
        LibMsg <what disambiguation>
        LibMsg <no pronouns known>
        LibMsg <person ignores command>
        LibMsg <cannot talk to absent person>
        LibMsg <cannot talk to inanimate object>
        LibMsg <Places initial text>
        LibMsg <Objects initial text>
        LibMsg <single object disambiguation>

    Section : Perceptive Characters

    Some actions fail because the player lacks a key. Some action fail because the player just remembered there isn't a door in the south wall. In the latter case, the player-character would most likely only look south before checking himself, and only perceptive NPCs would be able to comment on what they're pretty sure he was thinking of doing.
        LibMsg <first N objects>
        LibMsg <report implicit take>
        LibMsg <implicitly pass outwards through other barriers>
        LibMsg <implicitly pass inwards through other barriers>
        LibMsg <cannot drop clothes being worn>
        LibMsg <cannot insert clothes being worn>
        LibMsg <cannot put clothes being worn>
        LibMsg <cannot exceed carrying capacity>
        LibMsg <use holdall to avoid exceeding carrying capacity>
        LibMsg <cannot insert if this exceeds carrying capacity>
        LibMsg <cannot put if this exceeds carrying capacity>
        LibMsg <cannot take yourself>
        LibMsg <cannot take other people>
        LibMsg <cannot take something you are within>
        LibMsg <cannot take something already taken>
        LibMsg <cannot take possessions of others>
        LibMsg <cannot take component parts>
        LibMsg <cannot take hidden parts>
        LibMsg <cannot reach within closed containers>
        LibMsg <cannot take scenery>
        LibMsg <cannot take something fixed>
        LibMsg <cannot reach within other places>
        LibMsg <cannot remove from closed containers>
        LibMsg <cannot remove something not within>
        LibMsg <cannot drop something already dropped>
        LibMsg <cannot drop not holding>
        LibMsg <cannot insert something not held>
        LibMsg <cannot insert into something not a container>
        LibMsg <cannot insert into closed containers>
        LibMsg <need to take off before inserting>
        LibMsg <cannot insert something into itself>
        LibMsg <cannot put something not held>
        LibMsg <cannot put something on it-self>
        LibMsg <cannot put onto something not a supporter>
        LibMsg <cannot put onto something being carried>
        LibMsg <need to empty into a container>
        LibMsg <need to empty into something open>
        LibMsg <already empty>
        LibMsg <empty something into itself>
        LibMsg <cannot give what you have not got>
        LibMsg <cannot give to yourself>
        LibMsg <unable to receive things>
        LibMsg <cannot show what you have not got>
        LibMsg <cannot enter something already entered>
        LibMsg <cannot enter something not enterable>
        LibMsg <cannot enter closed containers>
        LibMsg <cannot enter something carried>
        LibMsg <cannot exit when not within anything>
        LibMsg <cannot exit closed containers>
        LibMsg <cannot get off things>
        LibMsg <cannot go that way>
        LibMsg <cannot travel in something not a vehicle>
        LibMsg <cannot go through concealed doors>
        LibMsg <cannot go up through closed doors>
        LibMsg <cannot go down through closed doors>
        LibMsg <cannot go through closed doors>
        LibMsg <nothing through door>
        LibMsg <cannot search unless container-supporter>
        LibMsg <cannot search closed opaque containers>
        LibMsg <nothing found within container>
        LibMsg <nothing found on top of>
        LibMsg <fake newly visible exterior>
        LibMsg <fake newly visible exterior nothing>
        LibMsg <cannot open unless openable>
        LibMsg <cannot open something locked>
        LibMsg <cannot open something already open>
        LibMsg <reveal any newly visible exterior initial text>
        LibMsg <no newly visible exterior>
        LibMsg <cannot close unless openable>
        LibMsg <cannot close something already closed>
        LibMsg <cannot lock without a lock>
        LibMsg <cannot lock something already locked>
        LibMsg <cannot lock something open>
        LibMsg <cannot lock without the correct key>
        LibMsg <cannot unlock without a lock>
        LibMsg <cannot unlock something already unlocked>
        LibMsg <cannot unlock without the correct key>
        LibMsg <cannot switch on unless switchable>
        LibMsg <cannot switch on something already on>
        LibMsg <cannot switch off unless switchable>
        LibMsg <cannot switch off something already off>
        LibMsg <cannot wear something not clothing>
        LibMsg <cannot wear not holding>
        LibMsg <cannot wear something already worn>
        LibMsg <cannot take off something not worn>
        LibMsg <cannot eat unless edible>
        LibMsg <cannot wave something not held>
        LibMsg <throw at inanimate object>
        LibMsg <not pushed in a direction>
        LibMsg <pushed in illegal direction>
        LibMsg <cannot push something fixed in place>
        LibMsg <cannot pull something fixed in place>
        LibMsg <cannot turn something fixed in place>
        LibMsg <cannot push scenery>
        LibMsg <cannot pull scenery>
        LibMsg <cannot turn scenery>
        LibMsg <cannot push people>
        LibMsg <cannot pull people>
        LibMsg <cannot turn people>

    Section : Involving darkness

        LibMsg <entering darkness>
        LibMsg <dark description>
        LibMsg <examine while dark>
        LibMsg <search while dark>
        LibMsg <look under while dark>

    Section : Involving conversation

        LibMsg <block showing>
        LibMsg <block saying yes>
        LibMsg <block saying no>
        LibMsg <block saying sorry>
        LibMsg <block swearing obscenely>
        LibMsg <block swearing mildly>
        LibMsg <block answering>
        LibMsg <block asking>
        LibMsg <block telling>
        LibMsg <telling yourself>

    Section : Involving others in a social or civilized context (as opposed to attacking)

    Sadly missing from this list of standard I-F actions would be "selling", "offering", "accepting", "caretaking", "diagnosing", "healing", "accusing", "blessing", "dancing", etc.
        LibMsg <report player giving>
        LibMsg <report npc giving>
        LibMsg <block giving>
        LibMsg <block buying>
        LibMsg <block kissing>
        LibMsg <squeezing people> - hugging, presumably
        LibMsg <block waking other>

    Section : In a social or civilized context, without involving others

        LibMsg <block praying>
        LibMsg <block singing>
        LibMsg <block thinking>
        LibMsg <block player consulting>
        LibMsg <block npc consulting>

    Section : Involving the senses and body needs

        LibMsg <block drinking>
        LibMsg <block tasting>
        LibMsg <block smelling>
        LibMsg <block listening>
        LibMsg <block sleeping>
        LibMsg <block waking up>
        LibMsg <report player eating>
        LibMsg <report npc eating>
        LibMsg <report player touching things>
        LibMsg <report npc touching things>
        LibMsg <report player touching self>
        LibMsg <report npc touching self>
        LibMsg <report player touching other people>
        LibMsg <report npc touching other people>
        LibMsg <report npc looking>
        LibMsg <report npc examining>
        LibMsg <report npc looking under>
        LibMsg <look under>
        LibMsg <player self description>
        LibMsg <examine undescribed things>
        LibMsg <examine direction>
        LibMsg <examine devices>

    Section : Mundane actions

    While in the lobby of Life, we check our pockets while we wait:
        LibMsg <report npc taking inventory>
        LibMsg <Inventory initial text>
        LibMsg <Inventory no possessions>
        LibMsg <report player waiting>
        LibMsg <report npc waiting>
    How about "fidget"?

    Jacket and car keys:
        LibMsg <report player taking>
        LibMsg <report npc taking>
        LibMsg <report player removing>
        LibMsg <report npc removing>
        LibMsg <report player dropping>
        LibMsg <report npc dropping>
        LibMsg <report player wearing>
        LibMsg <report npc wearing>

    Walking around:
        LibMsg <report npc searching>
        LibMsg <block vaguely going>
        LibMsg <report player entering>
        LibMsg <report npc entering>
        LibMsg <report player exiting>
        LibMsg <report npc exiting>

    Section : Highly Physical actions for Indiana Jones

        LibMsg <block attacking>
        LibMsg <block blowing>
        LibMsg <block burning>
        LibMsg <block climbing>
        LibMsg <block cutting>
        LibMsg <block digging>
        LibMsg <block filling>
        LibMsg <block jumping>
        LibMsg <block jumping over>
        LibMsg <block pushing in directions>
        LibMsg <block rubbing>
        LibMsg <block set>
        LibMsg <block setting to>
        LibMsg <block swimming>
        LibMsg <block swinging>
        LibMsg <block tying>
        LibMsg <block throwing at>
        LibMsg <block waving hands>

    Section : Devices and doodads

        LibMsg <report player inserting>
        LibMsg <report npc inserting>
        LibMsg <report player putting on>
        LibMsg <report npc putting on>
        LibMsg <report player opening>
        LibMsg <report npc opening>
        LibMsg <report player closing>
        LibMsg <report npc closing>
        LibMsg <report player locking>
        LibMsg <report npc locking>
        LibMsg <report player unlocking>
        LibMsg <report npc unlocking>
        LibMsg <report player switching on>
        LibMsg <report npc switching on>
        LibMsg <report player switching off>
        LibMsg <report npc switching off>
        LibMsg <report player taking off>
        LibMsg <report npc taking off>
        LibMsg <report player waving things>
        LibMsg <report npc waving things>
        LibMsg <report player squeezing>
        LibMsg <report npc squeezing>
        LibMsg <report player pushing>
        LibMsg <report npc pushing>
        LibMsg <report player pulling>
        LibMsg <report npc pulling>
        LibMsg <report player turning>
        LibMsg <report npc turning>

    Thank you for reading.