search

AnssiR66 / AlanStdLib

The Standard Library for ALAN Interactive Fiction Language
Other
6 stars 2 forks source link

Verb 'pour' on Liquid Lacks Checks for Closed/Locked Vessel #108

Open tajmone opened 3 years ago

tajmone commented 3 years ago

The pour VERB on liquid instances is not honoring the checks if a container is locked/closed — whereas the same verb applied on a LISTED_CONTAINER vessel behaves correctly!

tajmone commented 3 years ago

Problem Explanation

The problem seems to be specific to pouring liquids, instead of their container (vessel) due to the lack of added CHECKs on the liquid class.

In lib_verbs.i we find:

ADD TO EVERY THING
  VERB empty_on, pour_on
    WHEN obj
      CHECK ...

      AND obj IS open
        ELSE
          IF obj IS NOT plural
            THEN SAY check_obj_open2_sg OF my_game.
            ELSE SAY check_obj_open2_pl OF my_game.
          END IF.

The reason LISTED_CONTAINERs are working fine has nothing to do with the specific class, but with the base verb carrying out the due checks.

When trying to empty the liquid instead of its container (e.g. "pour wine") there are no checks for the open/close state of the liquid's vessel.

Non-OPAQUE Containers

EDIT: The reason these checks are not in place is because the Library assumes that every closed container is also OPAQUE — i.e. it's contents shouldn't be accessible to the player's command because whatever is inside an OPAQUE CONTAINER is out of scope in ALAN.

The problem showed up because I was implementing a NOT open bottle which wasn't OPAQUE, based on the rationale that it should be possible to see through a glass bottle:

THE wine_bottle IsA listed_container AT liqlab.
  NAME bottle.
  NAME wine bottle.
  Is openable. NOT open.

That's why in my (local) test, with a closed bottle of wine (i.e. needs to be opened with a corkscrew) I get:

> pour bottle
You can't, since the wine bottle is closed.

> pour wine
(taking the wine bottle of wine first)
You pour the wine on the floor.

But if I define the bottle as an OPAQUE CONTAINER the problem goes away.

So this isn't really a bug, but more of a design overlook of possible use cases, which brings the whole discussion back to my proposal of adding a transparency attribute (#49).

We probably should still add the due checks to verify if a liquid's vessel is open or closed, so that non OPAQUE containers don't slip through the CHECKs, breaking the library logic. But this should be a transitory solution, until we work out if and how to handle transparency in the library.

Solution

The solution would be to add on the pour* VERBs on liquid a similar CHECK:

      AND vessel of obj IS open
        ELSE
          "You can't, since" SAY THE vessel of obj.
          IF vessel of obj IS NOT plural
            THEN "is"
            ELSE "are"
          END IF. "closed."

If the liquid has a null_vessel, that is always open by default, so it should be safe to use with both liquids that have a vessel and those which don't.

AnssiR66 commented 3 years ago

Sounds good! We can add that bit of code.

tajmone commented 3 years ago

More Bugs Popping Up!

Have a look at the update test for liquids and its transcript (links added at the top), you'll see that are numerous more bugs that start to surface as we stress-test the liquid class. I think there are more to come as we carry on testing (vaguely remember having stumbled upon them on the Italian port).

AnssiR66 commented 3 years ago

Ok, to start somewhere, 'ex' is overridden because of the DOES ONLY in the 'examine' verb for liquids, right? I'll think about it tomorrow with a fresh brain, how to deal with that...

tajmone commented 3 years ago

@AnssiR66, I've edited the problem description above, realizing the issue only affects non-OPAQUE containers. This really brings back the whole discussion to the question of how to implement transparent containers in the StdLib — we'd expect a bottle or a fish-tank to be see-through containers, which reveal their contents even if closed, but should behave as closed containers with all verbs that attempt to dislocate their contents.

We should probably add the safety checks to ensure that all verbs that can remove the contents from a container explicitly check that it's not closed (for liquids, check their vessels). This would prevent unexpected behaviors, and enforce some consistency; but my guess is that without a dedicated transparent attribute the approach to see-through containers might be kind of weak and less predictable.

AnssiR66 commented 3 years ago

Yes, seems like a "transparent" attribute is needed, definitely. 'Opaque' is fine for closed boxes but not for bottles, water tanks etc.