In 10.1.2, only one of multiple statements to place a backdrop is implemented when at least one is implemented as a routine

I have already reported this, but as it seems there may be something of a hiatus in bug-fixing at present, I’m putting it up here in case authors start to bang their heads against it.

The locations that backdrops may be found in can be defined in three different ways: as a list of one or more individual locations, as a region, or as a description of locations (e.g. ‘outdoor rooms’, when ‘a room can be outdoors or indoors’). The latter two methods are implemented by Inform as routines that match a location against the relevant rule (respectively, being within the given region, or matching the given description of locations).

Note that in 9.3 (6M62) there are three differences between how you can define where backdrops are found in the original setup and how you can redefine where backdrops are found during play using ‘move (a-backdrop)…’ or ‘now (a-backdrop) is in (a-region)’ (See WI 8.8).

(i) in the initial setup, you can supply a list (or a series of lists) of named locations where a backdrop is found- with assertions such as ‘The Moon is in the Car-Park and the Lane’ and ‘The Moon is in the Planetarium and the Skylight Room’. You can’t do this with ‘move a-backdrop…’ or ‘now (a-backdrop) is in (a-region)’, which can only specify either a region or (in the former case only) a description of rooms.

(ii) in the initial setup, you can supply a number of separate definitions of where a backdrop is found (regions and/or named rooms), and these accumulate additively such that the backdrop will at the start of play be found in a location matching any of them. When you redefine where a backdrop can be found with ‘move a-backdrop…’ (or, equally, with ‘now (a-backdrop) is in (a-region)’) the backdrop will then only be found in the single region or description of locations given in that phrase. A redefinition replaces all previous definitions, rather than being additive to them. (This means that if you want to redefine to a list of named locations, you must do so by placing your list in a predefined region, e.g.:

Moonlit-rooms is a region. The Skylight Room and the Carpark and the Lane are in Moonlit-rooms.

so that you can write ‘move the Moon to Moonlit-rooms’ or ‘now the Moon is in Moonlit-rooms’

or as an alternative, make a definition that you can use in a ‘description of rooms’

Definition: a room is moonlit:
	if it is the Skylight Room or it is the Carpark or it is the Lane, yes;
	no.

or if you need to combine this with one or more regions, or descriptions of rooms, add those to this single definition, e.g.:

Definition: a room is moonlit:
	if it is the Skylight Room or it is the Carpark or it is the Lane, yes;
	if it is in the Outdoor-area, yes;
	if it encloses a window, yes;
	no.

and you can now write ‘move the Moon backdrop to all moonlit rooms’).

(iii) conversely, during setup you can’t assert ‘(a-backdrop) is in (description of rooms)’- if you want to use a description of rooms to set up your backdrop, you need to do it in a ‘when play begins’ phrase, e.g.:

When play begins:
	move the Moon backdrop to all moonlit rooms.

but, as noted above, this will override any other assertions you had made to set up your backdrop, so you need to move all of these to be included in your definition of ‘moonlit rooms’.

In 10.1.2, during setup you can still give one or more lists of named locations where a backdrop is found, and this works fine as long as you don’t also name any regions where the backdrop is found. If you name a region, a routine referencing just that region, or a routine referencing just one of your named rooms will be implemented and the rest of your list of named rooms and/or regions will be lost. Worse, if you name more than one region that your backdrop is found in, at most one of them will be implemented. In other words, if you need to go beyond a list of named rooms in setting up your backdrop, the situation becomes similar to when you redefine your backdrop during play, i.e. you can only have your backdrop found in one region. Of course, you can work round this by setting up a specific region to contain one or more other regions and/or a list of named rooms and using that region for your backdrop, e.g.:

Moonlit-rooms is a region. Outdoors-area is a region. Lane and Carpark are in Outdoors-area. Outdoors-area is in Moonlit-rooms. Skylight Room and Planetarium are in Moonlit-rooms.  The Moon is in Moonlit-rooms.

See this minimal example, which compiles differently in 9.3 and 10.1.2:

“Bug_Found_in_Regions” by PB

The Observatory Entry Lobby is a room. The Planetarium is east of the Lobby. The Skylight Room is east of the Planetarium. The Carpark is west of the Lobby.

The Outdoors Area is a region. The Carpark is in the Outdoors area. The Moon is a backdrop. It is not scenery. The indefinite article of the Moon is “the”. The Moon is in the Outdoors Area. The Moon is in the Skylight Room.

Test me with “w.e.e.e”

In 9.3,this compiles to:

with found_in [ ;

if (location == I127_skylight_room) rtrue; if (TestRegionalContainment(location, I129_outdoors_area)) rtrue; ]

with output:

Carpark
You can see the Moon here.

Observatory Entry Lobby

Planetarium

Skylight Room
You can see the Moon here.

In 10.1.2, this compiles to:

with found_in call_U1937

[ call_U1937;

if ((location == I_skylight_room_U1)) {

rtrue;

}

rfalse;

];

with output:

Carpark

Observatory Entry Lobby

Planetarium

Skylight Room
You can see the Moon here.

7 Likes