Recent Changes to the TADS 3 Library

A new mechanism in the Actor class makes it relatively easy to set it up so one or more non-player characters accompany the player character on travel. This kind of group travel is especially good for things like a sidekick character who goes everywhere the player does, and for tour guides or other escorts who are showing the player character where to go.

This mechanism is similar to the "follow" mechanism, which makes one actor attempt to follow another on each turn, but it improves considerably on regular following by customizing the messages. Normal following is a little awkward for explicit group travel of the sort that one wants with sidekicks and escorts, because the messages are so generic; the NPC almost seems to be wandering around on its own and just coincidentally showing up where the PC is. This new "accompanying" mechanism accomplishes much the same thing, but smooths out the messages a bit. First, rather than having the NPC trailing along after the fact, the new system sends accompanying NPC's on ahead; this means that the NPC's don't just wander in later as they do with normal following. Second, the message for the NPC's pre-departure is customized to make it clear that the NPC isn't departing, but is coming along with you. Third, on arriving in the new location, there's a customization hook for describing the NPC's presence in the new location specially for the group travel; this is important because it gives us a place to mention that the actor starts doing whatever it is the actor normally does in the new location. The overall effect is that each group travel action is made to look like a single, integrated action, rather than two generic and unrelated actor travel actions.

NPC's can also be set to accompany NPC's with the same mechanism, but it's much less interesting for that, since the main value of the new mechanism is that it improves the messages for PC-plus-NPC group travel. For NPC-plus-NPC group travel, this new mechanism has no particular advantage over the the simpler "follow" mechanism.

Setting up accompanying travel is relatively straightforward. You have to specify the conditions under which the group travel occurs, and you should customize two messages related to the travel. You set this all up by overriding methods on the NPC who's going to follow the lead actor (usually the PC). The methods to override are as follows.

First, override the accompanyTravel() method so that it returns true under the conditions where you want the accompanying travel to occur. This method is called each time your NPC is present and sees another actor attempt a travel action (it's called during your NPC's beforeAction when the action is a TravelVia). If you want your actor to accompany the PC everywhere, simply return true when the action actor is the PC. The method also has access to the TravelConnector involved in the travel, so you selectively accompany an actor for some destinations but not others, if you wish.

Warning: the next two parts are likely to be modified soon. I'd recommend against writing any code that makes customizations using these features right now.

Second, define an accompanyDesc method for your actor. This method is used instead of the usual actorHereDesc method to describe your actor in the new location immediately after the group travel is finished. It's usually desirable to use a special message to describe the actor right after the accompanying travel, because you usually want to convey that the actor is just arriving - not that the actor is walking in separately from the lead actor, but that the actor is arriving at the same time as the lead actor. If you do override accompanyingDesc, you should override accompanyingListWith to return an empty list ([]).

Third, you can optionally provide a special TravelMessageHandler for your actor by overriding getAccompanyingTravelMessageHandler. By default, this routine provides a message handler that uses messages like "Bob goes with you" instead of the usual "Bob leaves to the east" to describe the departure of your actor. The normal departure message isn't appropriate, because the actor isn't just leaving, it's leaving *with* the lead actor. The default "Bob goes with you" is better, but you might still want to override this handler to provide even more customized messages: "Bob escorts you to the east," or "You drag Bob with you," or whatever makes sense for the specific situation.

Finally, note that you can use accompanying travel and the regular following mechanism together. Regular following can be a useful fallback for cases you don't want to customize. Regular following occurs after the fact, because it occurs on an NPC's turn when the NPC sees that the actor it's tasked to follow is no longer present. Accompanying travel, in contrast, happens on the same turn as the lead actor's travel. This means that regular following is essentially overridden by accompanying travel, since it happens first.

For the purposes of matching vocabulary in the dictionary, quoted adjectives are simply treated as though the quotes weren't present. So, "QU" TILE is treated exactly the same as QU TILE. This means you don't have to worry about the quotes when defining your vocabulary words.

There is an additional bit of special treatment for quoted strings. The special vocabulary word '"*"' (that is, an asterisk within double-quote characters) serves as a wildcard for any quoted string. If an object defines this special wildcard as an adjective among its vocabulary words, then that object will match any quoted string as an adjective. This is the equivalent of the '#' wildcard string for numeric adjectives.

String-as-adjective phrasing is implemented using the new production literalAdjPhrase. This new production is now used wherever numberPhrase was formerly used in the role of an adjective in noun phrase rules. literalAdjPhrase matches numbers, '#' number phrases, and quoted strings.

The asDobjFor() approach had the drawback that the action synonyms didn't ever generate TravelVia actions proper, but simply called the TravelVia handlers internally; so, for example, beforeAction() routines wouldn't ever see a TravelVia action being performed. The new remapping approach is better because it means that every possible action on these objects that involves travel will go through an actual TravelVia action. This allows beforeAction() and similar routines to be assured that they can catch all travel actions by looking for TravelVia alone, eliminating the need to worry about synonym actions that could cause travel.

Another new class, BasicOpenable, provides the basic state management for openable objects (which can optionally be linked in pairs to maintain the same status across the pair) but doesn't provide any of the verb handling of Openable. This can be used for objects that want to maintain open/closed state using the usual method names, but which don't respond to direct player open/close commands.

IMPORTANT: Objects based on Openable and Lockable must not initialize their open status with isOpen or their locked status with isLocked. Instead, initialize the status with initiallyOpen and initiallyLocked, respectively. Also, be sure you never set isOpen or isLocked directly; instead, call makeOpen() and makeLocked() to effect these status changes.

In ShipboardDirection.defaultConnector, if the source location or any container has 'isShipboard' set to true, then we now use noTravel as the default connector rather than noShipTravel, as the latter is meant to convey that shipboard directions make no sense in non-shipboard locations.

Added a ShipboardRoom mix-in class that defines isShipboard to true.

Along the same lines, Door.connectorTravelPreCond() now calls a separate method, getDoorOpenPreCond(), to obtain the door-is-open precondition object. By default, this returns a doorOpen precondition (wrapped with an ObjectPreCondition for 'self'), so the default behavior hasn't changed.

>stand on platform
Okay, you are now standing on the platform.
Bill stands on the platform.
Bill follows you onto the platform.

The redundant "Bill follows you" has been eliminated.

>sit on red chair
(first standing on the red platform)
(first getting off of the blue platform)
(first standing)
Okay, you're now sitting on the red chair.

To the uninitiated, this looks backwards: shouldn't we stand up, then get off the blue platform, then get on the red platform, and then sit on the red chair? Of course, that's what's actually happening, and in its own way the transcript above reflects this: the second "first" applies to the first "first": it's saying "before you can stand on the red platform, you first have to get off the blue platform." Likewise, the third "first" applies to the second "first," to say "before you can stand on the red platform, you have to stand up first." In other words, the implied reports are nested recursively. The recursive structure isn't represented visually, though, so it's not evident whether one of the later "firsts" refers to the preceding "first" or back to the original command line. It would have been possible to represent the recursive structure visually, using indentation or something like that, but this probably wouldn't have made most people very happy; most non-programmers aren't accustomed to thinking in terms of recursion and stacks and tree views, and even programmers might well have found this kind of presentation to be too obviously mechanistic.

To improve the situation, the transcript processor now features a new transform, called implicitGroupTransform, that rearranges these recursive listings into an order that should be entirely straightforward to anyone, programmer or not. The new transform also consolidates these lists into a much more concise and readable format. The transformer does two things. First, it "unstacks" recursive lists of implied action announcements to put them into the chronological order in which the commands were actually performed; the transcript has always kept track internally of which announcement is tied to which action, so the new transformer can merely inspect these records to determine the action relationships and use this information to unwind the stack. Second, the transformer combines each run of adjacent implied action announcements into a single announcement, showing a list of the actions performed. The result is that the example above now looks like this:

>sit on red chair
(first standing, getting off of the blue platform, then standing on
the red platform)
Okay, you're now sitting on the red chair.

This new format should be easier for players to understand, since it shows implied actions in the order in which they're actually carried out, eliminating any need to be aware of the recursive goal-seeking work that the system is doing internally. Hopefully, players will also find it more readable and less obviously mechanistic than the old format.

Note that the literal is always in the IndirectObject role, regardless of whichLiteral, which only specifies the grammatical role for message generation purposes.

Likewise, assign the IndirectObject role to the topic in TopicAction. This will allow remapTo to be used with a TopicAction.

In particular, the message role only affects the way the object is used in generating messages based on the verb, such as "what do you want to open it with?".

To do this, add a verb rule for TYPE ON <object>, without any literal phrase. For most objects, fail in verification; but when verification passes, in the action, ask for a missing literal phrase. (This has the additional benefit that it makes it easy to create objects that allow generic typing on them, as in TYPE ON COMPUTER, for situations where the game doesn't want to make the player type anything specific but still wants to allow the generic act of typing on the object.)

>ASK BOB ABOUT
what do you want to ask him about?

>BILL
"Ah, yes, , very interesting..."

(The problem is that we're not propagating getOrigText() from the empty topic phrase match down to the underlying replacement match.)

>ASK BOB
what do you want to ask him about?

>ABOUT BILL
"Ah, yes, about bill, very interesting..."

(The problem is that we need an aboutTopicPhrase production to parse responses to ABOUT WHAT questions.)

Remove the special-cased plural filtering in AllPluralProd and DefinitePluralProd. Move this logic instead into Collective's filterResolveList() implementation.

Add a new Thing property, collectiveGroup, that allows an ordinary object to be associated with a CollectiveGroup object. In CollectiveGroup's filterResolveList() method, choose to keep either the individuals (the ordinary Thing objects associated via their collectiveGroup properties with a CollectiveGroup object) or the CollectiveGroup in the resolution list, but not both. By default, make the selection based on action; subclasses can override as desired to use other criteria.

CollectiveGroup can be used to create things like a "money" object to represent a set of coins and bills, so that a command like "look at money" can respond with a single description of all of the money present, rather than iterating over all of the coins and bills individually.

This will allow the traditional ordering, with actor "I am here" messages placed after the rest of the room description, while keeping the rest of the special descriptions grouped with the room's main description. Most special descriptions belong with the main room description because they're meant to be extensions of the room description. Some special descriptions are not; they're meant to describe more ephemeral status information, so work better when grouped with the other status-like messages. Actors in particular fall into the latter category, since actors are meant to seem autonomous, not parts of the rooms they occupy.

Override showSpecialDescInContents in Actor, so that we can show the type of description we previously showed using nestedActorLister.

Remove nestedActorLister and NestedRoom.examineNestedRoomActors().

The conversion of sentence-ending punctuation compensates for the elimination of the double-space insertion in the VM-level formatter. It also improves matters over the old way by making the treatment of sentence-ending punctuation customizable: the game can replace the filter method with its own custom conversions. This allows customization not only for stylistic variation but for language-specific conventions as well.

This would require a new set of VM-level functions in the tads-io set:

• logConsoleCreate(filename, charmap, width): returns a handle to the new console
• logConsoleSay(handle, ...): writes the arguments to the log console; works like say() and bannerSay()
• logConsoleClose(handle): closes the console

In addition, add a LogConsole library class to simplify operations with the log console. This class can be quite simple; it's just an OutputStream subclass that implements the writeFromStream method to call logConsoleSay().

(The mapPushTravelHandlers() macro essentially wants to decompose the two-object action into two single-object actions, which isn't safe with the regular asDobjFor() mapping. The difference with iobjAsDobjFor() is that this new routine temporarily makes the indirect object take on the direct object role, so that the target dobj handler sees the proper object in the direct object slot.)

This change will allow disambigName to be overridden without requiring all of the xxxDisambigName's to be overridden at the same time, because the xxxDisambigName's will by default apply the standard algorithms to the modified disambigName. At the same time, though, this has the virtue of the original implementation that, in the common case where disambigName is not overridden, any overrides to theName, aName, and countName will be used for the corresponding xxxDisambigName's. Furthermore, since these are all still separate methods, objects can still separately override each xxxDisambigName as needed for cases where the disambigName is customized and the customized name requires overriding the normal article algorithms.

While we're at it, add pluralDisambigName, using the same logic.

First, remove the special-case tokenizer handling for "'s" words that appear in the dictionary, so that we handle all "'s" words uniformly in the tokenizer: all "'s" suffixes are treated as separate tokens.

Second, never add "'s" words to the dictionary in initializeVocab(). Instead, define a new dictionary property, adjApostS; when we see a "'s" word in a vocabulary list, remove the "'s" suffix and add only the prefix to the dictionary, but add it as an adjApostS instead of as an adjective. (For simplicity, don't bother with nounApostS at all; allow only adjectives as apostrophe-s words.)

Third, add a new grammar production, adjWord, that accepts either a single adjective or an adjApostS followed by an apostrophe-s token.

Fourth, where appropriate, change 'adjective->' grammar rules to use 'adjWord->' instead.

These changes correct the problem that adding a literal "'s" word to an object's vocabulary prevented that word from being used as a true possessive phrase in the grammar. The old tokenizer rule was that a word that appeared with an explicit "'s" suffix in the dictionary was kept intact, rather than split into separate tokens for the root word and the "'s" suffix. Since the word was kept intact as a single token, it couldn't match the grammar rules for possessive phrases, which only match the separated form. These changes allow the same word to be used in either context, since everything is treated the same way in the tokenizer; even if a word is used as a literal vocabulary word with a "'s", it'll still be split up during tokenization. Even with this change, we can still match explicit "'s" vocabulary words, thanks to the adjWord grammar.

Note this has one small potential impact on existing games: if an object explicitly defines its own 'adjective' property (rather than using the automatic library initialization), and a word defined in the adjective list ends in apostrophe-s, then that word must be stripped of the apostrophe-s suffix, removed from the 'adjective' list, and added to a new 'adjApostS' list instead. Similarly, if any vocabulary words that end in apostrophe-s are dynamically added with G_dict.addWord(), the apostrophe-s words should be stripped of the suffix and added under the '&adjApostS' property instead of the '&adjective' property.

Add a subclass, Heavy, for objects that are immovable because they're very heavy. This is suitable for things like large furniture and big boulders.

In addition, especially with random atmospheric messages, it can get tedious to see the same messages over and over if you spend a lot of time in the same area. It's therefore often the case that we want frequent atmospheric messages when the player first gets to a location, but then we want the frequency to drop dramatically after the player has spent more than a few turns there. To make this easy to handle, add a couple of new properties: 'messageReduceAfter' is the number of times that we want to see messages at the initial frequency, and 'messageReduceTo' is a new value for 'messagePercent' that we'll apply after we've generated the messages 'messageReduceAfter' times. Make these nil by default, which means that there is never a reduction in the frequency. Authors can use these properties to generate random atmosphere messages at high frequency at first, but then drop the frequency to just an occasional message after the player has been in the location long enough to get the idea.

Split off a new method from each of Traveler.describeDeparture and describeArrival: describeNpcDeparture/Arrival, which is called when an NPC (or a traveler not involving the PC) is doing the travel. This will simplify overriding the messages for vehicles and other special travelers when desired, since the overriding method won't have to make all of the checks to see if it's the PC doing the travel.

ShuffledList: the basic shuffled selection class. Keeps a list of values, and returns a randomly selected element on demand.

ShuffledIntegerList: a specialization of ShuffledList that returns a randomly selected integer from a given range.

ShuffledTextList: a subclass of RandomTextList that makes its selection using shuffling rather than independent random selection.

openMsg, closedMsg, lockedMsg, unlockedMsg, onMsg, offMsg

statusStanding, statusSitting, statusLying, statusStandingOn, statusSittingOn, statusLyingOn

>close bag; x all in bag
red ball: You cannot see that. [etc]

We're incorrectly resolving the contents of an object for an "all in x" phrase, even when the contents can't be seen. We must filter the resolved objects to include only the visible contents.

askDisambig should provide an open <.parser> tag if and only if askAgain is false: this will let the mode flow in from the preceding re-prompt message from noMatchDisambig or disambigOrdinalOutOfRange. askDisambig should always close the <.parser> tag.

>take coin
Which coin do you mean, a gold coin, a silver coin, or a copper coin?

>second
Taken. [actually takes a gold coin, since more than one was present]

First, get rid of dobjForwardTo, iobjForwardTo, remapTIAction, dobjRemapTI, iobjRemapTI, dobjRemapTIReverse, and iobjRemapTIReverse.

Second, add a new mechanism that combines the old forwarding and remapping schemes into a single new system. Use syntax like so:

desk: Fixed
  dobjFor(Open) remapTo(Open, drawer)
  dobjFor(Close) remapTo(Close, drawer)
;

The first definition above maps the Open action, when applied to the desk, to a replacement action of Open applied to the drawer instead. The second does the same thing for Close. This replaces the old dobjForwardTo/iobjForwardTo scheme, so we no longer need forwarding at all. The difference with the new remapTo scheme is that we use a replacement action for the remapping - the remap for Open above is essentially like using replaceAction(Open, drawer) for the action definition of Open on the desk.

Further, consider this syntax:

lid: Fixed
  dobjFor(Push) remapTo(Open, jar)
  dobjFor(Pull) remapTo(Close, jar)
;

Here we've remapped not only the object (as we formerly did with forwarding), but also the action. The first definition above says to replace "push lid" with the new action "open jar."

Next, consider this:

ninjaThrowingStar: Weapon
  iobjFor(AttackWith) remapTo(ThrowAt, self, DirectObject)
;

In this case, we're doing what the old dobjRemapTIReverse did, but with considerably clearer syntax. We're saying that when we resolve the indirect object of "attack with" and find that it's the throwing star, we should remap the action to "throw at ", where is the original direct object of the AttackWith action. The important thing about using the "DirectObject" argument is that it tells us to use the pre-resolved match tree for the direct object if we haven't yet resolved the direct object noun phrase - this means that we'll be able to resolve that noun phrase in the context of the new action (ThrowAt) rather than in the original action (AttackWith) context.

The class should treat all of its immediate contents as components, so it should be based on Thing rather than Container or Surface. It should have two additional properties: one for a secret object that serves as the internal container, and another for a secret object that serves as the internal surface. Commands like "put in" and "look in" should be redirected to the internal container, if one is defined; "put on" and the like to the internal surface, if present. The contents lister must specifically show the contents of the secret internal container and surface as though they were contained directly by the outer object.

>look in stove
(First opening the stove)
Opening the stove reveals a loaf of bread.  The stove contains a loaf of bread.

It would be good to remove this redundancy: if we're opening something implicitly for a look-in command, we shouldn't bother showing what the opening reveals. (We can handle this in Openable's Open action handler: if the action is implied, and the parent action is LookIn with the same direct object, we can suppress the revelation message.)

>look in small alcove
You see nothing in it.  A trophy is visible...

(Perhaps if we special description items, and nothing listed, we should display no message at all.)

>put coin in bag
(first opening the bag)
Opening the bag reveals a keyring. Done.

Perhaps we should put that "done" on a new line - no paragraph separator, just a new line. (In general, perhaps when there's a non-default response from an implied command, we should add an "implied command terminator separator," which by default would simply be a newline.)

• Create a new US English subdirectory of the adv3 library directory; use ISO 639/3166 codes for the naming convention, so the US English directory is called en_us.
• Move us_eng.t to en_us/en_us.t
• Move us_eng.h to en_us/en_us.h
• Move msg_neu.t to en_us/msg_neu.t
• Add a new library, en_us/en_us.tl. Move the English-specific source file inclusions out of adv3.tl and into en_us.tl.
• Include the new en_us.tl library in the auto-generated makefile for the new-project wizard in Workbench. (We'll have to add a user preference at some point that lets the user select the language library to use, rather than using en_us.tl unconditionally.)

>open door with key
You see no door with key here.

In particular, it might be nice to recognize "<nounPhrase> <prep> <nounPhrase>" constructs specifically, and flag them as "command not understood" errors instead of "object not seen" errors. This could be handled by adding a "badness" production for np-prep-np structures for the prepositions commonly used in command phrases; by making this a badness match, we'll match it as a last resort when we can't find a valid verb phrase structure.

Likewise for Distant and Intangible.

>sit on darker chair
>sit on chair
Which one?
>darker

This is allowed, but shouldn't be - the reply should be "you're already sitting on the darker chair." (The problem is that we verify the lighter chair as okay, and we remember that we verified something as okay but don't bother remembering what; we need to track which objects we verify as okay individually.)

>sit on chair
>look
... You contain a keyring ...

(We shouldn't mention your contents in that manner. The problem is that Actor inherits contentsListed from Fixed; Actor should override contentsListed and set it to nil, since an actor's contents shouldn't be listed in the ordinary fashion in a room description.)

Add a new Thing property, contentsListedSeparately, that allows an object to control whether its contents are listed in the new in-line style, or as the traditional separate list. Make this nil by default.

>out
Out of what?
>e
You can't get out of that (the east wall).

It would be nice to treat such responses as new commands. We could probably adopt the heuristic that we give the new command interpretation priority over the noun phrase interpretation of a reply to this prompt. Anything that looks like both a syntactically valid noun phrase and a syntactically valid command probably matches the noun phrase syntax only because it's extremely abbreviated; the chances of the verb phrase match being an accident are somewhat less. In addition, it should be less confusing to the user to treat the response as a new command when a noun phrase was intended than vice versa, and it should be fairly obvious how to force a noun phrase interpretation (adding "the" would do the trick, for example).

  >i
  You are carrying a duffel bag (which contains a pen cup).  The 
  pen cup contains four pens.

Right now, we're not adding that bit about the pens, because we think we're done with the top-level list, as we've already listed everything: we scan the duffel, and decide that we don't need to recurse into it, since it's listed and has in-line listed contents. What we'd need to do is add another recursive descent to look for everything that we listed at the second (or deeper) level that has contentsListedSeparately.

>e
>put cup in desk
>undo

(Takes back turns through "e". The problem is that we're marking a remapped action as a nested action; it's not really nested, because the original action is completely replaced and will never reach the execution phase. Do not mark remapped actions as nested.)

>take book Which book do you mean, the red one, the blue one, or the green one? >blue Taken. >g

Should this 'take blue book' or should it ask... Which book do you mean, the blue one, or the green one?

Right now we use the literal tokens from the original command, so we ask the disambiguation question again. This is exactly what we want in cases with indistinguishables:

You see five silver coins here.
>take coin
Taken.
>g
Taken.

But in cases where we have distinguishable objects, we probably want the resolved objects, not the words.

We probably want to distinguish this way: if we had indefinites or indistinguishables, resolve again from the original text. Otherwise, use the original resolution.

>take coin
Which coin, a gold coin, or a silver coin?

>coin
Which coin, the silver coin, or the gold coin?

The second time around, the cardinality of the full list should not change, so we should be asking the same question as the first time.

As part of this, we need to find a way to say what object blocks a sense path opaquely, so that we can say why we can't touch something that we can see. There are two main cases: containers are in the way, and connectors are in the way.

Examples of specialized bags of holding: wallet, key ring, purse, duffel bag.

>take both coins
Which two (of five gold coins or three silver coins) do you mean?

>two gold
You don't see that many coins here.

The problem is that we disambiguate with the reduced match list.

>take coin
Which coin, gold, silver, or copper?

>all but copper

no worky - might even be a gram prod bug, since we seem to have a weird firstToken/lastToken value in these cases

>take gold coin, gold coin
gold coin: Taken.
gold coin: You're already carrying the gold coin.

When we have multiple equivalent items in scope, and we mention several items in a list, we should pick separate equivalent instances for each mention.

This should apply to disambiguation responses, too:

>take coin
Which coin do you mean, a gold coin or a silver coin?

>gold, gold

>i
You are carrying a paper bag.  The paper bag contains a key.

>drop key
(First taking the key)
Dropped.

>get coin
Which coin, a gold coin, a copper coin, or a silver coin?

>coin
Which coin, a copper coin, a silver coin, or a gold coin?

The re-ordering on the second round is weird - we should keep the order stable if we can.

>get ball
Which ball, red or green?

>blue
You don't see that here.

The error shouldn't be "you don't see that here" - it should be more like "that's not one of the choices you were offered." However, it would be better to widen the scope again to the real scope, rather than failing.

When establishing a new context, we check to see if the generator is in scope in the given sense. If not, we hide messages; if so, we show messages.

A nested context should actually be considered a context switch, because we don't want an enclosing hiding context to hide an enclosed showing context. For example, if we are generating messages with sight scope for Lloyd, and we have a nested context where Lloyd is saying something and so we now are in hearing scope for Lloyd, we want the nested context to show its messages if in fact Lloyd is in hearing scope even if Lloyd is not in sight scope (maybe the player character and Lloyd are in contact over a walkie-talkie).

We should see bob leaving on his third queued move, but we don't for some reason.

>bob, n. get silver coin.
>n

>get large red ball, small red ball and drop them
[works]

>get asdf red ball, small red ball and drop them
Don't know the word 'asdf'

>oops large
...you see no drop them here

Why does it pick out the right interpretation normally but can't on a token reparse?

>ask about watch
(asking Bob)

Most default messages are meant to be tagged onto the end of the command line, but when we're adding a direct object to a two-object verb, the added object goes in the middle of the command and hence the default phrase doesn't sound right when tagged onto the end of the command line. By adding the participle form of the verb, we make it clear that the default message stands alone as a new sentence (or sentence fragment, anyway) and is not meant as a missing continuation of the original command text.

The idea is that if we have two objects that are both ranked the same way on one axis but are distinguishable on another axis, we want to consider the axis on which they're distinguishable. For example, if we type "put silver coin in jar," and one jar is open and the other is closed, we want to pick the one that's open. At the same time, they'll both be ranked as equivalently logical on the basis that neither is held by the actor. We don't want the being-held status to override the open status, but we likewise don't want the open status to override the being-held status if both are open but only one is being held. The solution is to ignore the equivalent being-held status when both objects have this same value, and to ignore the equivalent open status when both have the same value, but still consider these attributes when they differ.

   iobjFor(AttachTo) asIobjFor(PutOn)

>dig in dirt
What do you want to dig in it with?

>with shovel

>ask
(Bob)
What do you want to ask him about?

>ask
(asking Bob)
What do you want to ask him about?

>watch
(asking Bob)

>ask
(asking Bob)

It would be better as simply

>ask
(Bob)

>go through passage
>again

This somehow keeps the old passage in scope. Must need to check scope again for 'again'.

(The problem is that the last action is hanging on to its cached resolver scope lists. We simply need to drop the old resolvers so that we start the new command with new resolvers.)

  for (pass = 1 ; pass <= 2 ; ++pass)
    run all verifiers
    for each precondition
      run this precondition, allowing implicit commands on pass 1 ONLY
    if no implicit commands were executed
      break

This would ensure that side effects of an implicit command are re-tested through previous preconditions. Each precondition would only be allowed to run its implicit command on pass 1 because this would prevent infinite loops from conflicting preconditions - on pass 2, if the condition isn't met by now, we'll assume it's not going to be, so we'll simply fail the command.

• on the first successful use of a key, automatically boost the likelihood for future disambiguation using the key if an option is set (this might be the default option)
• if the author wants the player character to know from the outset which key goes with a door, the author can add the key to the lockable's knownKeyList - this can be useful for games with obvious key associations or key associations known from the outset to the player character (for example, if the PC has a key to their own house, the ought to know what the key opens)

(trying each key on the keyring, you find that the iron key unlocks the door)

The problem is that the objHeld precondition is applying a likelihood of 80 because the iron key isn't held, and the held keys are getting 100's. Maybe we need to reduce the likelihood of any other keys or keyrings when the known key is present, but this seems like a poor special-case hack for a problem that is likely to arise in other contexts.

To solve this, add a 'priority' to logical results. Use low priority for precondition rankings, because these are inherently of lower importance than unique attributes of the objects themselves.

>move me to
What do you want to move it to?

Could we substitute "yourself" for "it" somehow?

>get key's jar
Which key's do you mean...

That should just be 'which key do you mean', not 'which KEY'S'

>bob's
unknown word ''s'

>get key
Which key do you mean...

>get bob's key
The word ''s' is not necessary...

The problem would seem to be that we don't handle 's in disambig responses and treat it as an unknown word.

>look under me
You see nothing unusual under you.

We should make that second 'you' into 'yourself' instead. In general, can we change an objective case use of an object already used in the nominative should to a reflexive instead?

>bob, x key
Which key?

>quit
This command cannot be directed to another character...

>lock door
(first closing the iron door)
(with the iron key)
Locked.

The defaulted indirect object is misleading. This should instead be:

>lock door
(with the iron key)
(first closing the iron door)
Locked.

The problem comes from the fact that "Lock" has an objClosed precondition for keyed lockable; "Lock" doesn't need this precondition, because "LockWith" has it. Removing the precondition will get the ordering right.

>type hello on typewri

>get iron key
You take the key and attach it to the keyring

>get keys
brass key: You take and attach...
rusty key: You take and attach...
iron key: Taken.

It's irritating that the last one is taken off the keyring. Should we leave items out of plurals when we have multiple logical items of different logicalness? (This isn't a completely academic problem, since you could in practice have a couple of new keys in a room that you want to pick up, without detaching keys you already have on the keyring. One easy way to solve this would be to use a different command for detaching from the keyring - require 'take key off keyring', and say Illogical('if you want to take the key off the keyring, say so'); but this could be irritating when you just want to take the key off the keyring.

>follow bob
Bob is right here.

>bob, u
You see no bob here.

>bob, n
>g

We're not checking to see if the actor is still in scope.

>n. open door.
>close door and sit down

This has something to do with the empty dobj noun phrase. Same thing happens with 'close door and open' (which also has an empty dobj), but not with 'close door and look' (which takes no dobj) or 'close door and sit down on floor' (which has a non-empty dobj).

Make use of this information in 'verify' routines for the earlier-resolved objects when applicable. For example, for "take from ", we resolve the indirect object first, so we don't know the final dobj resolution when resolving the iobj; so, use the tentative information so that we can rule an iobj illogical if there's no tentative dobj inside the proposed iobj.

Make "listen to x" and "smell x" defer to the associated objects.

For scoping, a sound or smell doesn't have to place the main object in scope, but rather can just put the intangible sensory emanation in scope. For example, if an alarm clock is buzzing, the 'buzzing sound' object would be in scope but not the alarm clock itself. (On the other hand, some sounds, like a ringing phone, might be sufficiently distinctive as to place the main object in scope. But for those cases we can simply associate the sound/smell with the main object.)

>listen to phone
It's ringing.
==> phone.soundDesc

>listen to ring [phone visible]
It's coming from the phone.
==> sound.soundWithSource

>listen to ring [phone not visible]
It sounds like a phone.
==> sound.soundWithoutSource

>look [phone visible]
...
The phone is ringing.
==> sound.soundHereWithSource

>look [phone not visible]
...
You can hear what sounds like a phone ringing.
==> sound.soundHereWithoutSource

• always show on room description, or only show on explicit "look" descriptions (and corresponding sense commands - "smell", "listen")
• show every n clock ticks
• show every n clock ticks for m iterations, then go to a secondary message every p clock ticks (for something like "the phone is still ringing").

The obstructor can be easily found with gActor.findOpaqueObstructor(sight, obj) (where 'obj' is the noise or odor object). Once the obstructor is found, we'll have to generate an appropriate message, which will require a new method parallel to obs.cannotReachObject(obj) - perhaps we could call it obs.describeSoundObstructor(obj) etc - which would display "The ringing seems to be coming from inside the box" and the like.

This entire mechanism would not be used when the obstructor itself cannot be seen, such as in the dark.

>look
...
You can hear what sounds like a phone ringing.

>listen to ring
It sounds like a phone.

>x phone
You don't see any phone.

It would be better if that last line were:

>x phone
You can hear a phone ringing, but you can't see it.

To deal with this, adjust the touchObj and objVisible preconditions so that it provides better feedback for an object that can be heard but not seen.

>take ball
Which ball, the red ball, or the green ball?

>third
There weren't that many choices - did you mean the red ball, or the
green ball?

>orange
That wasn't one of the choices - did you mean the red ball, or the
green ball?

However, if the response looks like a valid response but doesn't give us a match, and it also looks syntactically like a valid new command, treat it as a new command.

Text lists should be linkable to a common counter object, so that the lists are synchronized on the same counter. This lets you have separate lists for each room, but keep the timeline in each list the same.

It should be possible to associate a text list object with a room instead of coding the room's text list in-line in the room.

>take coin
Which coin, silver or gold?

We should probably keep the copper one in the list. In particular, we probably shouldn't remove an item from consideration for disambiguation just because it's less likely - once we've determined that the noun phrase is ambiguous, we should offer all logical matches, even when they're less likely.

>take coinc
Which coin...?

>take tricyc
The word 'tricyc' is not necessary in this story.

>take tricyc
Taken.

For some reason, truncated words are treated as misspellings when they appear in disambiguation responses.

(Experimental code has been added, conditionally compiled based on the SENSE_CACHE macro. We'll leave it on for the time being to get some experience with it to see how well it works.)

  You are carrying three matches (one lit), two flashlights (one
  providing light).