Backdrops argh!

I think I’ve already figured this one out, but it caused me such a huge amount of aggravation that I wanted to share it.

[code]The current mess is a backdrop that varies.

Definition: A room (called loc) is messy:
if the current mess is sand, decide on whether or not loc is sandy;
if the current mess is water, decide on whether or not loc is wet;

To update multitudes:
Now the current mess is water;
Move the water backdrop to all messy rooms;
Now the current mess is sand;
update backdrop positions;

A backdrop is usually not scenery.
the Water is a backdrop. the Sand is a backdrop.

The Road is a room. The Beach is west of the Road.

A room can be wet. A room can be sandy. The Road is sandy.

When play begins: update multitudes.

Every turn:
if the road is sandy, now the road is not sandy;
otherwise now the road is sandy;
update backdrop positions.

test me with “l/l/l/l”[/code]

I thought I could use the “messy” adjective, tied to a “current mess” variable, to update multitudes (a kind of backdrop) independently of each other. I should have realized, though - every time backdrop positions are updated, the description of objects that tells where they should be is checked again! So if “messy” refers to a different backdrop now, it doesn’t matter! All the backdrops get lumped together!

I think I can fix this with relations, but if not, I will scream.

Okay, I’m getting ready to scream.

Why is relation syntax so impenetrable?

Littering relates a multitude (called the mess) to a room (called the site) when the count of the mess in the site is at least 1. The verb to litter (he litters, they litter, he littered, it is littered, it is littering) implies the littering relation.

To update multitudes: Repeat with the mess running through multitudes: Move the mess backdrop to all rooms littered by the mess; update backdrop positions.

Why? Why, why, why, why, why? Am I going to have to scrap this whole )(*#&$)%ing extension just because of this idiotic constraint?

At this point I’m thinking I’ll have to forget the idea of using them as actual backdrops, and move them manually, somehow guessing at all the cases where the backdrops would normally get moved. Is there some way to replace or hook into the existing “update backdrop positions” phrase?

Hmm… maybe I can just put the damn things everywhere but be more careful about checking when the count is 0.

Oh, and I guess I’ll have to be careful to catch any attempt to interact with a multitude that isn’t really there…

I haven’t tested this, but why doesn’t the following work (in the code in your first post)?

To update multitudes: Now the current mess is water; Move the water backdrop to all messy rooms; update backdrop positions; Now the current mess is sand; Move the sand backdrop to all messy rooms; update backdrop positions;

Maybe I’m not understanding what you’re trying to do, but if you can tell me why that fails it’d be, um, edifying for me.

That’s what I had originally, but I pared it down to illustrate the problem.

What’s going on is this. The location of a backdrop isn’t a list of rooms or regions, it’s a description of objects. When you say “move the water backdrop to every messy room,” it sets the location of the water to “every messy room.” Every time the “update backdrop positions” phrase runs (e.g., after going), the world model checks if the location belongs to “every messy room.” If the meaning of messy has changed since then, the result will be affected. So if messy means sandy at that time, and the location is sandy, then the water will get moved to the location.

What I essentially did was to bypass the error message I got when I used a relation, but I didn’t actually solve the problem that the message told me about.

Here’s my tentative, hacky fix, which involves replacing the “update backdrop positions” phrase from the Standard Library:

[code]To update multitudes:
Repeat with the mess running through multitudes:
If the mess is presently available, move the mess backdrop to all rooms;
otherwise remove the mess from play;

To update backdrop positions:
update multitudes;
update I6 backdrop positions;

To update I6 backdrop positions:
(- MoveFloatingObjects(); -)

[/code]

Understanding has an “[something related by …]” token that assumes the object of the relation is always the object understood. Since this is also the case with multitudes (a multitude is present in every room that relates to it by the littering relation), I was hoping there was a syntax for that. Did I miss it?

I see. Argh indeed.