One room visible from another room? Scope?

Scoping stuff from a second room is a pain. Can you make the cell an enterable openable transparent container? You can fake it being a real location:

The sheriff's office is a room.
The jail cell is an enterable transparent open openable container in the sheriff's office.
before an actor going south when the location is the sheriff's office, instead try the actor entering jail cell.
before an actor going north when the jail cell holds the actor, instead try the actor exiting.

There are various default messages you’ll want to change, too, but it’s time for bed so I’m not going to try to comment on them…

2 Likes

Not a problem. Another quick note, I just looked at your code and error you mentioned again. You might try changing your lines:

After deciding the scope of the player while in the Sheriff's Office: place the Jail Cell in scope.
...
After deciding the scope of the player while in the Jail Cell: place the Sheriff's Office in scope.

to

After deciding the scope of the player while the player is in the Sheriff's Office: place the Jail Cell in scope.
...
After deciding the scope of the player while the player is in the Jail Cell: place the Sheriff's Office in scope.

Seems “while in the Jail Cell” caused the error, while “while the player is in the Jail Cell” (or Sheriff’s Office) works. My bad for not noticing that first.

This alone will let you examine things in the jail cell from the office (or vice versa). Though note you will have to actually have it described manually at some point. That is, if you put the key in the Jail Cell, you can type “x key” and it works, but it won’t actually list the key in your room description or anything.

There are many ways to deal with this. Using “list of things in Jail Cell” is one such that could be appended to various locations, such as:

The description of the Sheriff's Office is "An open doorway leads southwest to the village square. A jail cell rests at the north side of the office.Inside, you can see [list of things in Jail Cell]."

That does have the odd side-effect of saying you can see nothing. It makes sense, but may read oddly to you. It can be handled with a simple if-statement.

The description of the Sheriff's Office is "An open doorway leads southwest to the village square. A jail cell rests at the north side of the office. [if there is anything in Jail Cell]Inside, you can see [list of things in Jail Cell].[end if]"

Likewise, you could require more effort, such as looking at the door, searching it, or whatever else your story calls for. But if you want to TAKE the object from the outside, that is where the reachability I mentioned in the prior post goes into detail.

The jail key is in the Jail Cell.
A rule for reaching inside Jail Cell when the noun is a the jail key and the player is in Sheriff's Office: say "You reach through the narrow bars of the jail door and scoop up the key."; allow access
1 Like

Dredging up old memories of version changes…

I believe “while in [room]” is an old syntax that was removed a few versions ago, in…6L38, I think? The issue is that “while in [room]” and “while the player is in [room]” behaved slightly differently—the former was a synonym for “while the location is [room]”, so it would be true if the player was e.g. in a vehicle in the room, while the latter would not be. This was considered unnecessarily confusing.

The examples should have been updated for this; you can just say “when the location is [room]” now.

EDIT: Nope, it was 6L02. Finally found it in the changelog.

3 Likes

Thanks for all the tips, everyone! I’ll experiment with it tonight.

Thanks to some extensive efforts to clarify this by @drpeterbatesuk, I’ve come to understand that something being “in scope” effectively means that the parser will try to match words of player input to it when generating a command. If an object is not in scope, it can’t be the noun or second noun of an action, or the person asked for a command to an NPC.

Scope is by default driven by the visibility relation per the spatial model provided by the Standard Rules. Scope can be modified with rules related to the deciding the scope of... activity.

The parser checks the words of player input against all objects determined to be in scope. Use of the keyword any in a grammar line for an action, e.g. Understand "consider [any thing]" as considering. for a hypothetical considering action, lets the parser alter the scope for the purposes of evaluating that grammar line only. (I think.)

You want generic changes in scope, so the rule-based approach is probably best. You probably want to use the phrase place the contents of <room> in scope though – otherwise the room object itself is placed in scope, which is atypical.

In addition to basic questions of scope, the parser will eliminate objects from consideration if they don’t match the profile specified by the grammar line. As an example, the someone keyword requires that the matched object be a person, so Understand "chat with [someone]" as chatting. won’t let the command >CHAT WITH MAILBOX parse as the action chatting with the mailbox unless the mailbox is a person (or another person-derived kind), or unless there is a person whose name matches (e.g. a person called a mailbox repair technician) that is in scope. Things added to scope count as “visible” in the narrow sense seen in action definitions such as Considering is an action applying to one visible thing.; note that this is not exactly the same sense of visible as the visible adjective defined by the Standard Rules, which relies on the visibility relation (i.e. the ability to see things according to the spatial model).

After the parser resolves scope and successfully matches a grammar line, an action is generated and the action processing rules kick in. (These are the well-known Before, Instead, Carry out, etc.) Just after the Before rules are processed assorted lesser-known rulebooks kick in, most importantly here the one involving reachability. Any action that requires a touchable object will fail if the object can only be seen by the actor. Many actions in the Standard Rules require this, sometimes perhaps unexpectedly. You will need to write rules to allow any exceptions to reachability that you want to enable. (This sort of thing will be an issue whether you set up the jail cell as a separate room or an enterable container.)

As Zed says, you can just make the cell into a container and avoid the hassle of scope modification entirely. That approach probably fits better with the implicit world model used by Inform.

Speech-like actions (i.e. asking it about, answering it that and telling it to) all require that the target of the spoken content be touchable – this seems to be used as a proxy for modeling continuity of the air medium between the actor and the target, as the same applies to the listening and smelling actions. You’ll have to make some modifications so that talking with people in the cell will work.

Asking about is speech-like action.
Answering that is speech-like action.
Telling about is speech-like action.

A container can be porous.

The gaol is a locked enterable transparent porous fixed in place container in Sheriff's Office.

The player carries a brass key. The brass key unlocks the gaol.

A person called a jailbird is in the gaol.

Reaching inside something porous when speech-like action: [these require touchability, not just visibility]
    allow access.

There are still more things to deal with to get the output to look “pretty,” but a rule for writing a paragraph about the gaol will probably serve well for that purpose.

If you want to go the multiple rooms route, then similarly (and note that this is very close to RB Ex 366 “Rock Garden”):

Mutual visibility relates rooms to each other in groups. The verb to be clearly visible from means the mutual visibility relation.

The Jail Cell is clearly visible from the Sheriff's Office.

Definition: A room is expansive if it is clearly visible from a room that is not it.

After deciding the scope of the player when the player is in an expansive room:
    repeat with R running through rooms clearly visible from the location:
	    place the contents of R in scope.

After looking while the player is in an expansive room:
    repeat with R running through rooms clearly visible from the location:
	    carry out the  printing the locale description activity with R;
    continue the action.

Definition: A room is surveyed if it is clearly visible from the location.

Reaching inside a surveyed room when speech-like action:
    allow access.
4 Likes

This is a very confusing aspect of Inform syntax.

The narrow sense of “visible” seen in action definitions such as Considering is an action applying to one visible thing. is actually synonymous with “in scope”, rather than the sense of visible defined by the visible adjective, i.e. something which can be seen. Objects placed in scope using the ‘deciding the scope of’ activity become forcibly “in scope” (and so “visible” in the first sense, i.e. they can be referred to in a command in order to generate an action) but they are not at the same time necessarily made “visible” to the player/actor in the latter sense- i.e. if the player/actor couldn’t see them before, then they still can’t necessarily see them- they will only be made “visible” in the latter sense if the player/actor is not in the dark.

For more information on the meaning of scope, see here.

1 Like

And of course “one visible thing” in action definitions being broader than “one thing”. Out of all the weird inconsistencies in Inform’s syntax, I think this one qualifies as the most confusing.

I don’t know what a better adjective for “need not be touched” would be, but if anyone invents one it could be worth a pull request (not to remove “visible thing” but to add an alternative to it).

1 Like

Probably nothing better than ‘one thing in scope’…

1 Like

“one visible thing” means “one thing in the game” so a single word version could be “one diegetic thing” but you’d have to be a certain kind of literature, writing, or gaming nerd to already know that word…

2 Likes

If the world could be made anew, the best approach would probably have been to have:

‘one object’ to mean one object in scope (equivalent to ‘one visible thing’ as Inform actually has it)

‘one touchable object’ to mean one touchable object (equivalent to ‘one thing’ or ‘one touchable thing’ as Inform actually has it)

‘one carried object’ to mean one carried object (equivalent to ‘one carried thing’ as Inform actually has it)

Sadly, we must live in the broken world as it is :frowning:

2 Likes

er, I don’t think we can say that. Actions don’t care about scope. Grammatical tokens in understand lines care about scope. one visible thing means that the basic accessibility rule won’t care whether the noun is touchable and the carrying requirements rule won’t care whether the noun is carried. That is, that any game object – direction, room, region, or thing (in or out of play) could be usable with this action, provided an understand line gets us there.

Lab is a room.
Conservatory is a room.

fooing is an action applying to one visible thing.
understand "foo [any thing]" as fooing.
understand "foo [any room]" as fooing.
understand "foo [any region]" as fooing.

report fooing: say "Foo [noun]."

The house is a region.
The box is a thing. [out of play]

test me with "scope / foo conservatory / foo north / foo house / foo box".

yields

>[1] scope
1: yourself (582487)
 
>[2] foo conservatory
Foo Conservatory.
 
>[3] foo house
Foo house.
 
>[4] foo box
Foo box.
 
> 

edited to correct myself: The basic accessibility rule already doesn’t care if the noun is a region or room; with one visible thing it also won’t care whether or not the noun is a direction, or a thing that isn’t present or can’t be touched.

2 Likes

An interesting semantic distinction.

I have always thought of [any …] tokens as overriding the usual requirements of scope implicit in constructing any action from a command, but I see how understanding ‘Understand tokens’ as the policemen of scope makes more sense, philosophically and in how the parser and action-processing actually operate. So in this paradigm:

Action definitions:
(i) restrict whether one or two objects and/or values can be used in the construction of an action
-these restrictions apply whether the action is constructed from a command, e.g. ‘Take the banana’ or in code, e.g. ‘try taking the banana’
-any action to be generated from a typed command or in code must match this basic definition or be rejected by the parser or compiler respectively
(ii) may add certain other requirements which are tested after the action is constructed and action-processing is already underway
-i.e. touchability/carriage of objects and/or the presence of light- specifically after the Before stage has had opportunity to intervene (by, for example, trying an ‘implicit take’ for an object which must be carried.)

Between the operation of stages (i) and (ii) defined in the action definition, in the case of actions generated from typed commands, Understand tokens:
(a) may restrict further what kinds of objects or values can be referred to in the command in order for it to be successfully translated to an action
- e.g. [someone] means that an object referred to in the action definition as a ‘visible thing’ must in fact, in a typed command, be a person
(b) enforce scoping rules, such that in the absence of the preceding word or prefix ‘any’, only objects that are ‘in scope’ can be referred to in a typed command in order to to construct an action
-N.B. scope does not apply to values, so for example [number] does not require ‘any’ to precede it (although [any number] does compile)

Naturally, as suggested above ‘Understand tokens’ are only used in parsing typed commands, not when code generates actions as in ‘try taking the banana’. Consequently, scope plays no part in code-generated actions, which can ignore all usual considerations of scope.

Similarly, code can generate actions including objects that no ‘Understand’ line would allow. For example, if you have 'Understand “Insult [someone] as insulting” as the only typed command-based syntax for the insulting action, code can still say ‘try insulting the banana’, which will not only compile but will also generate and run the action to insult the banana, ignoring restrictions of both scope and person.

However, restrictions to do with touchability, carriage and requirement for light appearing in an action definition will still kick in after the Before stage of any code-generated action. So if the action definition of insulting is ‘Insulting is an action applying to one touchable thing’, ‘try insulting the banana’ will only work if the banana can be touched, (barring any intervention at the Before stage to make it touchable).

3 Likes

Thanks for all the feedback. I haven’t had the opportunity to work on my game for the last few days, but I’m sitting down with it again now. I’m trying to implement the jail cell as a transparent container in the sheriff’s office.

Currently the description of the sheriff’s office is:

The description of the Sheriff's Office is "An open doorway leads southwest to the village square.[paragraph break]To the north is a [jail cell].[if there is anything in the Jail Cell]  Through the bars you can see [a list of things in the Jail Cell].[end if]".

Yielding:

Sheriff's Office
An open doorway leads southwest to the village square.

To the north is a jail cell.  Through the bars you can see a doodad.

You can see Sheriff Ogo and Deputy Glupp here.

>

Consequently, the view from the jail cell is:

Sheriff's Office (in the jail cell)
An open doorway leads southwest to the village square.

To the north is a jail cell.  Through the bars you can see yourself and a doodad.

You can see Sheriff Ogo and Deputy Glupp here.

>

which I’d rather be something like:

The description of the Jail Cell is "In the cell you can see [list of things in the Jail Cell].[paragraph break][if there is anything in the Sheriff's Office]Outside the bars, you spy [a list of things in the Sheriff's Office].[end if]".

Though obviously this is a description of a container and not a room description. Apparently it’s not possible to put nested ifs in a room description so I can’t just put [if the player is in the jail cell][otherwise] in the description of the Sheriff’s Office (because there are other ifs in these descriptions). Is there a simple way to toggle the room description based on whether the player is in the room proper vs in the container in the room?

A workaround for this is to break out the description into a full routine, e.g.:

The description of the Sheriff's Office is "[office_description]"

To say office_description:
    if ....
        if...
    otherwise...
1 Like

A strength of I7 is how modifiable and customizable it is, and the rules surrounding room descriptions are a great example of this. But that modifiability means there are a lot of moving parts and it’s hard to learn what bits you should change for what.

Check out Room Descriptions in the Recipe Book and its examples. And daunting as it is, read Chapter 18: Activities in Writing in Inform: most of how room descriptions are generated are in various activities, detailed there.

I’ll try to get into some specifics tomorrow…

1 Like

If you’re willing to be flexible about the structure of your output in order to work with the default machinery for room descriptions, something along the lines of the following may do the trick:

Rule for writing a paragraph about the gaol (this is the view of the cell from the office rule):
    say "To the north is a jail cell. Through the bars you can see [a list of things in the gaol]."

Definition: a thing is incarcerated rather than unincarcerated if it is enclosed by the gaol.

Rule for printing the locale description of Sheriff's Office when the player is incarcerated (this is the view of the office from inside the cell rule):
    say "The Sheriff's office is to the south. Through the bars you can see [a list of unincarcerated visible things that are not the gaol]."
1 Like
The description of the Sheriff's Office is "[office_description]".

To say office_description:
	if the player is in the Jail Cell:
		say "In the cell you can see [list of things in the Jail Cell].[paragraph break][if there is anything in the Sheriff's Office]Outside the bars, you spy [a list of things in the Sheriff's Office].[end if]";
	otherwise:
		say "An open doorway leads southwest to the village square.[paragraph break]To the north is a [jail cell].[if there is anything in the Jail Cell]  Through the bars you can see [a list of things in the Jail Cell].[end if]".

When in the Sheriff’s Office, there’s an unexpected paragraph break and indentation when describing the jail cell. Any idea why that’s happening?


To the north is a jail cell.
  Through the bars you can see a doodad.


You can see Sheriff Ogo and Deputy Glupp here.

>

The view from the jail cell lists the jail cell, even though I used “the jail cell is undescribed”. How do I stop that?

Sheriff's Office (in the jail cell)
In the cell you can see yourself and doodad.

Outside the bars, you spy Sheriff Ogo, Deputy Glupp, and a jail cell.


>

I will check out those sections of the doc. Thanks.

I think this does most of the job. It wasn’t easy.

The Sheriff's Office is a room. [no description]

The jail cell is an transparent enterable openable lockable container
  in the Sheriff's Office.

The spam is in the jail cell.

Sheriff Ogo is a person in the Sheriff's Office.
Deputy Glupp is a person in the Sheriff's Office.

Definition: an object is empty rather than occupied
  if the first thing held by it is nothing.

Definition: a thing is alone if the first thing held by the holder of it is it
  and the next thing held after it is nothing.

Before an actor going north when the Sheriff's Office holds the actor,
 instead try the actor entering the jail cell.

After entering the jail cell, try looking.

Before an actor going south when the jail cell holds the actor,
  instead try the actor exiting.

For printing the name of the Sheriff's Office when the player is in the jail cell:
  say "Jail Cell". [Jail Cell in status line]

For issuing the response text of the room description heading rule response (C)
  when the player is in jail cell: do nothing. [don't say (in jail cell) ]

For issuing the response text of the you-can-also-see rule response (F) when the player is in jail cell: say " through the bars." [instead of "here"]

For printing a locale paragraph about the jail cell when the player is in jail cell:
  say "[We]['re] in jail. ";
  unless the player is alone begin;
    say "[We] [can] see ";
    list the contents of the jail cell, as a sentence, including contents,
      giving brief inventory information, tersely, not listing concealed items;
    say " [here].[paragraph break]";
  end unless;
  say "To the south is the Sheriff's Office. [run paragraph on]";
  now the jail cell is mentioned; [ensures it's not mentioned again as being in office ]

For printing a locale paragraph about the jail cell when the player is not in the jail cell:
  say "To the north is [the jail cell]. ";
  if the jail cell is occupied begin;
    say "Through the bars, [we] [can] see ";
    list the contents of the jail cell, as a sentence, including contents,
      giving brief inventory information, tersely, not listing concealed items;
    say " in the cell.[paragraph break]";
  end if;
2 Likes

Thanks a million for going through the effort of coming up with that!!! It does indeed solve most of my problems, especially when combined with @otistdog’s bit about speech-like actions and porous containers. I do foresee myself having one more issue with this jail model in the future, but I have another scene to script first before I start dealing with that (and I may be able to adapt a solution from what has already been provided in this thread). I think this pretty much does it though. I had no idea it would get that complicated, but I have learned some things from this thread and am greatly appreciative for the help!