more than one enterable container/supporter

I was hoping I could find a post already on this topic, but I had no luck. If I have more than one enterable container/supporter in the room, and the player only types “get in” or “get on”, how can I get the parser to understand what the player implied? For example, I have a rocking horse, a couch, and a closet. As a player, after I examine the couch, if I typed “get on”, then I’d naturally mean to get on the couch. Yet the parser might assume that I meant to get on the rocking horse or to get in the closet.

I assumed that the parser would presume the last used noun, such as with examining/taking, i.e. “examine the horse” followed by “take it”. Yet when I am testing my game, this does not seem to be the case for enterable objects.

The two cases you mention are rather different: if you say “it”, the parser will indeed refer to the last used noun. (Try “get in it” or “get on it”.)

You can use a “rule for supplying a missing noun” or a “does the player mean” rule to make the parser supply an object automatically. Note that using a “rule for supplying a missing noun” requires there to be a grammar line without the noun in it.

okay, so after reading up a little bit on both of them (i’m still pretty uncomfortable with making and applying new rules), it seems like the one that is more appropriate for me is the “supplying a missing noun” rule. Is there a way to use the rule in order to get an effect similar when saying “it”?

Here’s along the lines of what I was thinking, which I’m 100% sure won’t actually work.

Rule for supplying a missing noun while entering:
   if the previously used noun is the horse:
        now the noun is the horse;
   if the previously used noun is the couch:
        now the noun is the couch;
   if the previously used noun is the locker:
        now the noun is the locker.

or maybe even

Rule for supplying a missing noun while entering:
   now the noun is the previously used noun.

Yes, this will work. Of course, you’ll need to tell Inform what you mean by the “previously used noun”.

The previously used noun is an object that varies.
After entering a thing (called the current container) in the rocking horse room:
        now the previously used noun is the current container;
        continue the action.

Rule for supplying a missing noun when entering in the rocking horse room:
       now the noun is the previously used noun.

Note: if you don’t write a “supplying a missing noun” rule for entering, then the default “find what to enter rule” runs (it is listed last in the “for supplying a missing noun” rules). It just picks an arbitrary enterable thing in the location. There’s no randomness involved, so it will always pick the same one—generally the one declared first in your source code.

I think it worked. Thanks! I guess I won’t know for sure until it gets beta-tested, but for now it seems to do what I wanted it to. Only I changed it to “After examining…” because I’m assuming the player would want to enter a particular container/supporter after examining it/interacting with it.

This will pick up any interaction:

After doing something when the location is the rocking horse room:
       if the noun is enterable:
             now the previously used noun is the noun;
       if the second noun is enterable:
             now the previously used noun is the second noun;
       continue the action.

Be aware that overriding the default parser behaviour like this will lead to inconsistencies. Why should the entering action in this particular room remember the last-used noun, when no other action does? (Of course, there’s sometimes a good reason to make a special case.)

the game itself is a one-room game, so the horse, couch, and closet are all in the same location. i’m trying to account for instances when the player is vague about the command, i.e.

OPEN CLOSET. GET IN.

or

X HORSE. GET ON.

or

PUT (some item) ON COUCH. GET ON.

Initially, every time I tried the “get in/on” command without supplying a noun, it automatically assumed I wanted to get on the horse, but I’m guessing that has to do with what you mentioned about it choosing the first enterable object in the source code.