I’m considering another extension idea, for representing multiple objects with backdrops:


Section - Multitudes

A multitude is a kind of backdrop.

Section - The Littering Relation

Vague quantity is a kind of value. The vague quantities are none, single, a couple, a few, and a great many.

Littering relates one multitude to various rooms. The verb to litter (he litters, they litter, he littered, it is littered, he is littering) implies the littering relation.

The littering relation has a vague quantity called the amount.

Section - Updating Multitudes

The current mess is a multitude that varies.
Definition: A room is messy if it is littered by the current mess.

To update multitudes:
Repeat with the mess running through multitudes:
Now the current mess is the mess;
Move the mess backdrop to all messy rooms;
update backdrop positions.

When play begins:
update multitudes.

Section - Invocations

Gravel is a multitude.

The quarry is a room. The quarry is littered by gravel.

The road is west of the quarry.[/code]

This code compiles as long as I leave out the line “the littering relation has a vague quantity called the amount.” I was afraid that wouldn’t work, but I don’t want to give up on it if the only problem is that I’m using the wrong syntax.

What I want is basically a table listing the amount of each multitude in each room. So if I were to implement it as a table, it would have to have (number of rooms * number of multitudes) rows. That sounded like a relation to me, except that it needs a third column for the amount. So - can it be done with a relation? Or, is it possible to create a table with a calculated number of rows? Or should I just have a fixed number of rows and try to figure out how to fail gracefully if it overflows?

Dynamic Tables can do that for you.

Thank you, gravel, for replying about gravel!

I would like to avoid using dynamic memory if possible. I noticed in the Standard Library there is a table defined with a special syntax “with blank rows for each thing.” I was wondering if there was some way to take advantage of that syntax or the code for allocating relation memory, in order to allocate what I need.

If you can define the number of rooms and the number of multitudes when you build the game, you can make a table with the appropriate number of rows (N*M). Or you could make N tables with M rows each, and (for example) have a table name property on each multitude. There are a few ways you can do it. I think they all involve some cutting and pasting of repetitive declarations.

I just noticed another potential problem with tables. Is it impossible to use a “multiple key” to reference a table row?


[code]Table of Littering
Substance Field Quantity
a multitude a room a vague quantity
with enough blank rows

To decide whether (site - a room) is littered by (mess - a multitude):
Unless there is a substance of mess and a field of site in Table of Littering, no[/code]
That will not compile. Is there a syntax that will, or do I have to repeat through every row?

Are you saying that if I wrote the extension for others to use then I would have to tell authors to manually create their own tables? Or is there some sort of macro feature of I7 that could be used for code generation?

You can’t actually have a numeric expression in the line “with X blank rows,” can you?

No, there’s no compile-time macro language. I’ve run into a number of situations where one would be useful, though (I think there’s a request on uservoice, maybe buried within another request…?).

For an extension, I’d just use one table and give it a fairly high number of blank rows. Warn your users that they may need to extend the table with more rows and clearly explain how to do it. That’s how most existing extensions that are based around tables work.


Ah. Yeah, then I’d do what Erik suggested. It’s no biggie, as long as the extension writer gives people a heads up.

All right then, I think I’m ready to go ahead with this. But before I get too crazy with it, let me ask:

Do you think there is a need for this? Does something like this exist already?

Here’s the specifics of what I intend to do:

Each multitude will have an associated thing, a “specimen.” There will be exactly one specimen in the game world. When the player does not carry the specimen, it will be part of the backdrop. The specimen can be taken, interacted with, whatever, but the player will be prevented from having more than one. I think this works well for the use I have in mind, but I want to know if it’s general enough.

My rationale is that if you really want multiple objects, there’s probably less overhead in making your multitude a kind and creating a bunch of clones. But do other people really want something like this?