About Liquids Contents

[tajmone]

Ciao Annsi,

I have a question about liquids. I've noticed that in lib_classes.i their header is thus declared:

  CONTAINER
    HEADER "In" SAY THE THIS. "you see"
    ELSE "There is nothing in" SAY THE THIS. "."

But I also noticed that neither room descriptions nor examining a liquid ever gets the HEADER text printed. I.e., although liquids are not OPAQUE CONTAINERS, it seems you can't get a list of whatever is inside them.

The verbs examine and look_in, implemented on the liquid class don't seem to refer to the liquid's HEADER either:

  VERB examine
    DOES ONLY
      IF vessel OF THIS <> null_vessel
        THEN
          IF vessel OF THIS IS open
            THEN "You notice nothing unusual about" SAY THE THIS.
            ELSE "You can't, since" SAY THE vessel OF THIS.
              IF THIS IS NOT plural
                THEN "is"
                ELSE "are"
              END IF.
              "closed."
              -- Here we prohibit the player from examining
              -- a liquid when the liquid is in a closed container.
          END IF.
        ELSE "You notice nothing unusual about" SAY THE THIS. "."
      END IF.
  END VERB examine.

  VERB look_in
    DOES ONLY
      IF vessel OF THIS <> null_vessel
        THEN
          IF vessel OF THIS IS open
            THEN "You see nothing special in" SAY THE THIS. "."
            ELSE "You can't, since" SAY THE vessel OF THIS.
              IF THIS IS NOT plural
                THEN "is"
                ELSE "are"
              END IF.
              "closed."
              -- Here we prohibit the player from looking into
              -- a liquid when the liquid is in a closed container.
          END IF.
        ELSE "You see nothing special in" SAY THE THIS. "."
      END IF.
  END VERB look_in.

Why liquids with a null_vessel or an open vessel just say "You see nothing special in..."? Wouldn't a DESCRIBE or LIST statement be useful there?

I was thinking of a lake or swimming pool in which the player can throw object, and other actor can enter and swim, etc. How would descriptions and examination show the lake/pool contents?

[AnssiR66]

Yes, you're right. DESCRIBE or LIST is definitely the way to go here. We can change this. -Anssi

---

From: Tristano Ajmone notifications@github.com Sent: Tuesday, December 4, 2018 9:23 PM To: AnssiR66/AlanStdLib Cc: Subscribed Subject: [AnssiR66/AlanStdLib] About Liquids Contents (#49)

Ciao Annsi,

I have a question about liquids. I've noticed that in lib_classes.i their header is thus declared:

CONTAINER HEADER "In" SAY THE THIS. "you see" ELSE "There is nothing in" SAY THE THIS. "."

But I also noticed that neither room descriptions nor examining a liquid ever gets the HEADER text printed. I.e., although liquids are not OPAQUE CONTAINERS, it seems you can't get a list of whatever is inside them.

The verbs examine and look_in, implemented on the liquid class don't seem to refer to the liquid's HEADER either:

VERB examine DOES ONLY IF vessel OF THIS <> null_vessel THEN IF vessel OF THIS IS open THEN "You notice nothing unusual about" SAY THE THIS. ELSE "You can't, since" SAY THE vessel OF THIS. IF THIS IS NOT plural THEN "is" ELSE "are" END IF. "closed." -- Here we prohibit the player from examining -- a liquid when the liquid is in a closed container. END IF. ELSE "You notice nothing unusual about" SAY THE THIS. "." END IF. END VERB examine.

VERB look_in DOES ONLY IF vessel OF THIS <> null_vessel THEN IF vessel OF THIS IS open THEN "You see nothing special in" SAY THE THIS. "." ELSE "You can't, since" SAY THE vessel OF THIS. IF THIS IS NOT plural THEN "is" ELSE "are" END IF. "closed." -- Here we prohibit the player from looking into -- a liquid when the liquid is in a closed container. END IF. ELSE "You see nothing special in" SAY THE THIS. "." END IF. END VERB look_in.

Why liquids with a null_vessel or an open vessel just say "You see nothing special in..."? Wouldn't a DESCRIBE or LIST statement be useful there?

I was thinking of a lake or swimming pool in which the player can throw object, and other actor can enter and swim, etc. How would descriptions and examination show the lake/pool contents?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/AnssiR66/AlanStdLib/issues/49, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AF2lHtSk-HJZm2R0cDS7YvlFgj6XbD64ks5u1svKgaJpZM4ZBVvf.

[tajmone]

This is probably an area where the Library could improved, but it will require some careful thinking, both in terms of considering the different types of liquids an author might want to implement (transparent, opaque, etc.), as well as their natural context — distinguishing between small and big quantities of liquids, whether they are without a containing vessel (a lake) or with vessels that might fixed in place (a pit) or otherwise.

We've already discussed elsewhere (if I remember correctly) that the current system doesn't cover well many implementation scenarios, e.g. how a liquid is being referenced in the messages when dealing with a lake, where the player will refer to its implicit contents (drink water, rather than drink lake) in his commands, rather then using the name show in descriptions and mentioning.

The implementation might be quite complex, for we need to evaluate the problem both in terms of its possible semantics, as well as its technical implementation details (attributes, ways for authors to customize/override verbs responses, etc.).

I'm sure that it's doable. The challenge is accomplishing it in a flexible way that doesn't make it hard on authors to create liquid entities in their adventures.

This is definitely a long term goal, and a feature that requires careful planning and testing on a dedicated branch before integrating it into the library codebase (like we did with the new clothing system).

[AnssiR66]

Would the solution be something like coming up with a default message that doesn't mention the instance? For example "That's not possible." or similar? Ok, let's imagine there is a lake, and the author implements "water" as a synonym for "lake" (as you mention above). Now, "take lake" should not be possible but "take water" should. If I remember correctly, the default response here is "You can't carry the (instance) around in your bare hands." which would be fine for the water and even (just so-so) for the lake. With "drink", "water" would be sensible but "lake" nonsense, or something warranting a joke reply. We could ask: is this something we need to worry on the library level, or is this something we just would guide the author to worry about themselves? For example, "lake" could be instructed to be implemented as a normal container object, and "water" should be the Liquid object in it. With "drink", we could just assume on the library level that "There is nothing drinkable here.", and the author could decide if the hero should be able to drink the water.

[tajmone]

The main discussion for this specific problem of the dual nature of liquids and their vessel was being discussed in #48. We better keep the discussion there, to simplify following it.

I only mentioned the general problem here, as a reminder. But I think that the solution for this is going to be through and extra string attribute indicating the alternative text to be used when referring to the liquid contents instead of its vessel (e.g. "water" instead of "lake" or "river". But there are also many other problems with liquids right now, e.g. transparency vs opacity (i.e. should the fishes in a like be visible when examining the lake? or the items inside a fossil-oil pool be hidden to view, and only discoverable by "searching" the pool?

We need to further develop the discussion in #48, by producing real case examples, implementing them in the test suite, and then trying different library fixes in dev branches, until we're satisfied — but we need to postpone this to after the v2.2.0 release, because we're very tight on time right now, and might even not make it for mid-November if new problems come up that we need to fix.

[tajmone]

Adding Transparency Attribute

I have been tinkering for quite a while with the idea of adding an attribute for transparent containers — e.g. Is not transparent, as the default value on EVERY thing.

Liquids can be transparent (like water) or opaque (like raw fossil oil, which is black), so the former should reveal its contents by merely examining the liquid, while the latter should hide its contents on examination, but reveal them with search.

Likewise, containers in general can also be transparent, although closed and even locked — e.g. a fish tank, you should be able to see the fishes inside, but not take them if the tank is closed. The same applies to vessel instances, e.g. a glass bottle should reveal its contents, a tin can not so; etc.

Adding a transparency attribute could be useful in many contexts, including custom extensions to the library by its end users.

Of course, this would add an additional layer of extra works in the various verbs that need to handle it — e.g. ensuring that if a container is transparent it will not be set to OPAQUE; as well as adding all the required checks and extra code to the verbs; etc. But I think it's worth it, not only for liquids but for containers in general.

But we could start with liquids, since usually vessel-less liquids are transparent in nature, and many vessels are frequently transparent too.

If the new feature plays out well, we could think of adding to all containers types (LISTED_CONTAINER) and their verbs.

[AnssiR66]

How about the in-built OPAQUE CONTAINER feature? Wouldn't that be sufficient here?

[tajmone]

How about the in-built OPAQUE CONTAINER feature? Wouldn't that be sufficient here?

I'm not sure. I vaguely remember that I when I carried out some tests to experiment with this feature I came to the conclusion that keeping them opaque would be better, but I don't remember why this was so. Possibly, it's because in ALAN opaque also implies inaccessibility of contents, and not opaque would make the contents both visible and accessible to the Hero.

To much time has passed since I was trying this out, all I remember is that there were some tricky aspects to keep in mind, especially since the container would need to be possible to be close, yet its contents visible from the outside. I'm quite sure that there was a need to add the transparent attribute in order to achieve this.

Basically, we would have to either keep it opaque but render their contents visible on examination (by LISTing them); or the other way round, keep the container not opaque but prevent access to their contents if it's transparent but closed. Or maybe we might just end up ignoring entirely the opaque attribute, and just rely on transparent and closed.

The problem is that for ALAN the opaque keyword impacts both visibility and access at once, which is the normal use, but with transparent containers we're basically separating these two aspects and trying to control them separately.