Liquids: infinite loop in deciding the scope activity?

Before you try this code, let me warn you that my computer got seriously hung up when I ran it:

[code]A vessel is a kind of container. A vessel can be full or empty.

Water is a thing.

After deciding the scope of the player when the player can see a full vessel:
place water in scope.

Instead of doing anything with water:
Now the noun is a random full vessel;
Try the current action.

Up the Hill is a room.

The well is a full vessel in Up the Hill.

Test me with “s”[/code]

After trying various permutations of this, it seems that the hang happens when going but not when waiting. Maybe waiting doesn’t check scope? Usually the action results in a hang, but once I got a runtime error of “too many activities going at once.” I’m guessing this is because of the “after deciding the scope of the player…” line.

Since this does seem to play hell with my computer, I thought I should post this before I do any further experiments. Please let me know if you have ideas or suggestions.

To know whether the player can “see” something the game has to check scope. After it has done that, it runs into the “after deciding the scope of the player” rule and needs to check the scope again, and so on. (“The player can see X” is the same as “X is in scope”.)

So is there a way to have an object “tag along” to the scope of another object without infinite recursion?

In this case, I’m wondering if something like this would work:

Understand "[water]" as a full vessel

You can use a simpler test than “can see”. (Example 351, Ginger Beer, does it with a “…while the small end is carried by the player” test.)

Otherwise, the easiest solution is to not use the scope mechanism directly. Rather, make one object part of (or contained in) another object.

If you need something to be “part of” several objects, you’d have to create a bunch of proxy objects and write “instead of doing whatever to X, do whatever to Y” rules.

Speaking of “part of,” I was doing something with a pump that has two ends. I made the ends parts of the pump, but it seems that when one end of the pump goes inside a container, it stops being part of the pump. Are the “contained by” and “part of” relationships mutually exclusive?

Just checked - this doesn’t work because you can’t use adjectives in an Understand phrase that way.

I tried this:

A vessel is a kind of container. A vessel can be full or empty.

Water is a thing.

Understand “[water]” as a vessel when the item described is full.

Up the Hill is a room.

The well is a full vessel in Up the Hill.
The bucket is an empty vessel in Up the Hill.

Test me with “get water”[/code]
But that also causes the interpreter to crash. I’m not sure “the item described” refers to the object understood, but it was the only syntax I could come up with that didn’t cause a compiler error.

It seems like I can prevent the crash by changing “water” into a token rather than an actual thing, though. Can anyone tell me why?

What’s causing the interpreter to crash appears to be “[water]”. If you remove the brackets, there’s no stack overflow. I think you should be able to get a working version going with this change. (At present, ‘get water’ causes the player to pick up the well, and without the player being alerted to that fact.)

Yes, “the item described” is the right way to refer to the object being understood. See 16.17 in the manual.

As Jim says, the example works (as far as it goes) when you remove the brackets around “water”.

You’ll get nicer output if you make the vessel a kind of thing, instead of a kind of container. Right now your “full” vessels are actually containers with no contents, which is why the room description keeps writing “(empty)” after them.

Alternatively, you could keep them as containers, and put water objects in them (as normal contents).

Either approach will work, but both will take additional fiddling.

Yes. That is, an object can have only one parent in the general sense: it can be contained in something, or part of something, or supported by something, or carried by somebody. But only one of the above.

(That’s why we call it an object tree. :slight_smile:

If you want two objects to be manipulated separately, but still “stuck together” in some sense, you have invented a form of the rope problem.