Defining things with tables results in adding properties at the room level

We know that the function described in WWI §16.16 (Defining things with tables) is somewhat defective at the moment and that the necessary fixes are already included and planned for the next version of Inform.

In particular, if we take the example “Tour des Maillots,” this line of code:

Some jerseys in the Staging Area are defined by the Table of Honorary Jerseys.

compiles, but its in-game result is not as expected:

Staging Area
You can see a yellow jersey, a polkadot jersey, a green jersey and a white jersey here.

>examine yellow jersey
Since 0, the Tour de France has awarded this jersey to the .

This problem is easily circumvented:

Some jerseys [in the Staging Area] are defined by the Table of Honorary Jerseys.

When play begins:
    repeat with LocalThing running through jerseys:
        now LocalThing is in the Staging area.

This produces the desired results:

>examine yellow jersey
Since 1919, the Tour de France has awarded this jersey to the race leader.

>examine green jersey
Since 1953, the Tour de France has awarded this jersey to the highest point scorer on sprints.

>examine white jersey
Since 1975, the Tour de France has awarded this jersey to the best cyclist aged 25 or less.

>examine polkadot jersey
Since 1933, the Tour de France has awarded this jersey to the King of the Mountains.

Furthermore, we know that the documentation’s suggestion:

It’s even possible to define kinds this way, though it’s rare to need to create many kinds at once. (See the worked example “Reliques of Tolti-Aph” at the Inform website. There’s no special syntax needed: rather than saying “Some jerseys are defined by…” we would say “Some kinds of jersey are defined by…”)

does not currently work (a fix is planned as mentioned above). Here, it is entirely possible to restore this function in the current version of Inform by declaring the kinds in the traditional way and then completing their properties using tables. It is a bit more complicated to achieve, especially if these kinds are used both for generating duplicates and unique objects, but it works well. This second feature is not involved in the problem I am encountering.

Here’s what I observe: let’s go back to our “Tour des Maillots” example.

>showme staging area
Staging Area - room
    white jersey - jersey
    green jersey - jersey
    polkadot jersey - jersey
    yellow jersey - jersey
    yourself - person
lighted, visited; singular-named, improper-named
description: none
printed name: "Staging Area"
printed plural name: none
indefinite article: none
list grouping key: none
year established: 0
citation: none

“year established” and “citation” are now room properties. I observe the same phenomenon in my WIP.

However, when checking the index:

room (plural rooms) 

Represents geographical locations, both indoor and outdoor, which are not necessarily areas in a building. A player in one room is mostly unable to sense, or interact with, anything in a different room. Rooms are arranged in a map.
Usually lighted not dark, unvisited not visited.
Can have description (text), map region (object).
Staging Area 

The unexpected properties are not mentioned. In my WIP, I declare numerous properties for rooms. Only the expected properties are listed in the index. The others, resulting from the use of “Defining things with tables,” are not displayed.

What would you advise? Should I be concerned about the future stability of my game? Or is this a side effect only affecting the output of the showme command, without any real impact on processing?

1 Like

Some additional information below, with a slightly modified version of Tour des Maillots.

"Tour des Maillots"

The Staging Area is a room. A jersey is a kind of thing. A jersey is wearable. Some jerseys [in the Staging Area] are defined by the Table of Honorary Jerseys. The description of a jersey is "Since [year established], the Tour de France has awarded this jersey to the [citation]."

The Cafeteria is a room. The Cafeteria is west of the Staging Area.

When play begins: repeat with LocalThing running through jerseys: now LocalThing is in the Staging Area.

Table of Honorary Jerseys

Table of Honorary Jerseys
jersey	year established	citation
a yellow jersey	1919	"race leader"
a polkadot jersey	1933	"King of the Mountains"
a green jersey	1953	"highest point scorer on sprints"
a white jersey	1975	"best cyclist aged 25 or less"

The year established is usually 1902.

Results:

Tour des Maillots
An Interactive Fiction
Release 1 / Serial number 240819 / Inform 7 v10.1.2 / D

Staging Area
You can see a white jersey, a green jersey, a polkadot jersey, and a yellow jersey here.

>examine a yellow jersey
Since 1919, the Tour de France has awarded this jersey to the race leader.

>showme cafeteria
Cafeteria - room
lighted, unvisited; singular-named, improper-named
description: none
printed name: "Cafeteria"
printed plural name: none
indefinite article: none
list grouping key: none
year established: 1902
citation: none

The addition of unwanted properties in the output of the showme command affects all rooms, not just those where the objects related to these properties are placed. These added properties have their default value (which can be 0 or none if nothing else is specified).

Moreover, I cannot find any trace of the year established and citation properties in the index.

Well, bad new, the showme command do not lie:

When play begins:
	repeat with LocalThing running through jerseys:
		now LocalThing is in the Staging area;
	if (the year established of the Cafeteria is 1902):
		say "the year established of the Cafeteria is 1902";
	otherwise:
		say " the Cafeteria do not have such a property".

Result:

the year established of the Cafeteria is 1902
Tour des Maillots
An Interactive Fiction
Release 1 / Serial number 240819 / Inform 7 v10.1.2 / D

Staging Area
You can see a white jersey, a green jersey, a polkadot jersey and a yellow jersey here.

>
``

End of the journey.

It does not seem possible to remove a property assigned to a room once it has been configured.

To avoid cluttering the properties of rooms, it is better not to use the ‘Defining things with tables’ function directly, but rather to:

  • declare the objects in the traditional way (a grey bag is a luggage);
  • assign an UID to each of these objects (a thing has a number called UID. The UID of a grey bag is 43);
  • then use a table and a repeat-loop to assign the appropriate properties to each luggage object, using the UID as the index.

Of course, this is only useful for easily producing and maintaining a large number of objects and/or properties.