Lit Property for Thing with Dark Property for Room

This is more just to ask why this makes sense since clearly everything works. Rooms have a “lighted” and “dark” property. Things have a “lit” or “unlit” property.

Consider this:

The Sinister Cave is a dark room. The flaming torch is in the Sinister Cave. The glass case is a container in the Sinister Cave. It is closed and openable.
Here we have a situation where the room will be “dark” and the glass case will be “closed”. Were I to open the case, the property of the glass case would change to “open”. So that makes sense. Properties updated based on their state. However, that does not seem to be the case for rooms.

Add the following:

The flaming torch is lit.

Then observe:

Note that the cave is still listed as a property “dark” (unlike the glass case, which would change from “open” to “closed” with the same kind of showme action).

Obviously everything still works so this isn’t reporting a bug. It’s more just a question of clarification and understanding:

Why doesn’t the room property become “lighted” when the room has a light source?

Clearly the room can’t be considered “dark” when a light source is present any more than the glass case could still be considered “closed” when it became “open.” I realize it could be argued that the room itself is not “lighted” because it’s the torch that’s lit, not the room. Yet there is an implicit assumption that all rooms have some vague light source in them which makes them “not dark” to begin with.

Perhaps more to the point, it would seem that if I wanted to test if the room was “dark” or “lighted” I couldn’t do so just based on whether a light source was in the room, which is what came up in one of my classes.

Seems like “dark/light” is an intrinsic property of the room rather than something that tells you whether it’s lit up at the moment. The case changes from “closed” to “open” because you’ve directly changed one of its properties–the room doesn’t change from “dark” to “light” because you haven’t directly changed the property. Whether or not you can see in the room depends on a calculation that involves whether the room is dark, whether a lit object is in it, and other stuff.

Testing whether the room is lighted in your sense is actually pretty difficult in native I7, as you can see from the “Unblinking” example in the documentation (that also explains some of the stuff I’ve just said, more authoritatively). But Draconis just posted a simple way to use the I6 routine that checks it:

Definition: a room is light-filled if the I6 routine "OffersLight" says so.

…at least, it’s supposed to be a simple way. I can’t get it to work and I’m not sure why. I will beep Draconis.

EDIT: Oh, the parenthetical that creates the Lexicon entry is necessary:

Definition: a room is light-filled if the I6 routine "OffersLight" says so (it is lighted or has a light source or something).

The parenthesized text doesn’t do anything in the story file but I guess Inform wants it there.

What’s interesting is I can have this:

[code]The Sinister Cave is a dark room.
The glass case is a container in the Sinister Cave. It is open and openable.
The flaming torch is in glass case.
The flaming torch is lit.

Every turn:
if the Sinister Cave is dark, say “The room is dark.”;
if in darkness, say “You are now in darkness.”[/code]
It leads to an interesting bit of text:

We can see that in the first turn, the room is listed as dark even though it is not actually. (It is from Inform’s perspective; but it’s an odd disconnect from the model world to how you express a check of the model world.)

Crucially note that I don’t see the text for the “if in darkness” conditional. So, to Inform, I’m not in darkness but the room is dark. (Again, reading things simplistically.) On the last turn, I’m getting both phrases – as expected with what we are discussing here. So this is more just one of those interesting things. I’ll definitely be writing up these distinctions in my class manual.

This is why I wish the “light-filled” property were in the Standard Rules. (Though I suppose I should come up with a good antonym for it.) It’s much more intuitive than the “lighted” and “dark” properties.

“Lighted” and “dark” have their place though: they’re exactly the same as “lit” and “unlit”, and I believe they even set the same flag in the underlying I6 representation. So if you have overhead lights in a room, a light switch should make the room “lighted” or “dark”, but intuitively should not also extinguish the player’s torch.

This is because the every turn rules run before the adjust light rule in the turn sequence.

This is one way of telling Inform to adjust light levels out-of-sequence (without printing announcements, which we might not want). Perhaps someone knows a less convoluted way of achieving the same thing? Of course we could just modify the turn sequence, but that could have knock-on effects. Or we could use Draconis’s Inform 6 trick to bring about more or less the same effect.

Adjusting is an activity.
For adjusting: follow the adjust light rule.

Rule for printing the announcement of darkness while adjusting: do nothing.
Rule for printing the announcement of light while adjusting: do nothing.

Every turn:
	Carry out the adjusting activity;
	if in darkness, say "You are now in darkness."

The philosophical answer is that we have to keep track of two distinct predicates for rooms/things: whether they provide light, and whether they are illuminated. Inform’s model is that the former is a property (lighted/lit) which the author sets; the latter is computed every turn.

(If we tried to handle both these concepts with a single property, we’d get nonsensical behavior – a room would get stuck with the lighted property the first time you carried a torch in.)

Open/closed is different; there’s only one predicate. (Which can be set either by the author or by library code, e.g. the standard carry out opening rule.) You can imagine an automatic door whose openness is computed every turn, but you can do that by setting the open/closed property. You don’t need a second property.

The down side to Inform’s lighting model is that computing illumination is expensive. (You have to iterate down through all objects in a room, paying attention to opacity of containers and so on.) So Inform uses some fairly harsh optimizations: it only runs the computation once per turn, and only for the player’s location. (With a second pass if the player moves.) You run into the limits of this plan once you start asking questions about illumination in other places.

I should add that things also require both of these predicates. In principle you could ask the same question you’re asking about rooms – how come this sword doesn’t have the “lit” property when it’s in an illuminated room?

But we implicitly optimize (further) by saying that a thing is illuminated just when it is in an illuminated location. I guess that’s sufficiently taken for granted that you didn’t ask that.

Yep, that reverse question was very much in my mind and is actually what started asking it from the other point of view. I really appreciate all this context. It’s immensely helpful to me and it definitely provides even more insight for my classes as to why the design of these systems is so interesting.

Hey, once again I stumble across some old code I’d forgotten about!

So, as Zarf says, “light-filled” (= containing light) is a predicate (not accessible by default, but the one-line hack adds it in), while “lit/lighted” (= providing light) is a boolean property. But if we want to sacrifice some of that optimization, we can make “lit” be decided by rules instead!

If you include Alternate Lighting System, you can write “special light calculation” rules which decide whether an object is a light source or not. For instance:

	Special light calculation:
		if the light-calculation object is affected by frotz, rule succeeds.
	Special light calculation:
		if the light-calculation object is phosphor-coated, rule succeeds.
	Special light calculation for the brass lantern:
		if the lantern is switched on, rule succeeds;
		rule fails.

	First special light calculation for something on the Pedestal of Impenetrable Darkness:
		rule fails.

At least an order of magnitude less efficient, but much easier to tinker with.

Perhaps I’m belaboring the point, but it makes sense: A dark room is still dark even if you bring in a lit candle. The looking and examining actions (among others) require light from some source; either the room, or a lit thing in a dark room. Bringing a light emitter into a dark room does not specifically cause other objects, nor the room itself, to change their properties to emanate light.

It makes sense to Inform and it makes sense when you start to think in Inform, so to speak. But this is where the intuitive human modeling and Inform modeling necessarily have to part ways and that’s always interesting to ferret out.

“Dark” in human usage doesn’t mean entirely without the ability to see (i.e., “pitch black”), which is how Inform treats it. A room can be dark but I can still see in it. Modeling a world would recognize that, in human terms, a room is no longer “pitch black” (Inform’s “dark”) if you bring in a lit candle. Likewise, a room with all the shades and curtains drawn can be still be “dark” (in human terms) but not “pitch black” (Inform’s conception of it).

If I turn on the lights in a room, likely no one would say “The room is still dark.” Inform would say that. That’s the interesting divergence. And to Inform that notion of “dark” is the case whether or not we’re talking about a room full of light or a room only partially lighted due to a candle.

Interesting. Recognizing that the “dark/lighted” property for a room is not whether or not you are able to see in the room but whether the room itself emanates light is potentially a good way to look at it.

Even speaking to Inform’s model, though, if the property of “dark” to Inform means “you can’t see in the room and can’t interact with objects you are not holding”, that property no longer remains true if there is a light source in the room. And if that property, as described no longer remains true, it’s at least worth questioning why the model and the intuition don’t link up.

This is good stuff! Believe it or not, while this can seem like ruthless nitpicking, it provides fun challenges for what I’m currently using Inform for, in terms of how my classes are engaging with it.

This is why I phrased stuff in terms of “provides light” and “is illuminated”.

Writing successfully in Inform 7 requires getting over the hump of “it’s written in English, but not exactly”. It’s like a non-native speaker in that certain phrases don’t grok exactly the same way one can assume.

“Lit” specifically is an adjective that means “this thing emits light”. If a “lit” object is in a dark room and in scope, it allows the player to use verbs that “require light” such as looking and examining.

A human would describe the room as “lit,” but in the Inform physical model, a “dark” room remains dark even though the “lit” object overrides that for the purpose of commands.

It is possible to define a new version of “darkness” that isn’t just binary pitch black.


A room can be darkened.

To decide if the location is dim:
if the location is darkened:
if the player can touch a lit thing:
decide no;
decide yes.

The Library is a room. “The shadowy stacks of books fade into the gloom to the north.”

A candle is in Library. It is lit.

The Bookstacks is north of Library. It is darkened. “Though you can barely see, you feel the shapes of hundreds of books around you. It’s even darker to the east. [if the location is dim]You can’t make out any of the titles due to the dimness of this area[otherwise]Your light source reveals detail in a small radius around you[end if]. The library is better-lighted to the south.”

a book is here. “One [if the location is dim][otherwise]interesting-looking [end if]book has fallen to the floor.” The description is “[if the location is dim]It’s a dusty book, but that’s all you can make out.[otherwise]This is the book you’ve been looking for![end if]”.

The Archive is east of Bookstacks. It is dark. “These books here are rarely seen, since it’s hard to navigate even when the Library is open and the main lights are on. There’s nothing interesting here. You’d better go back to the less gloomy area to the west.”[/code][/rant]



Agreed. These cases, however, are not so much about English writing per se, because the same problem would appear in Inform 6 with modeling “dark.” This is about a human-intuitive model versus the machine-model, so to speak. Although I agree that it can be conflated to some extent when a natural language abstraction layer.

That’s actually the really interesting thing about all this for some of the classes I work with. These are the same problems developers and testers deal with, for example, when the business domain model cannot be faithfully represented in the application model.

Yep. Great example! I’m totally stealing it. And this is the other fun part. Gradually aligning the relatively vanilla model with a human model. This is very similar to what developers and testers do when they work with tools like SpecFlow or Cucumber. Those are particularly relevant because they allow you to use natural language that delegates down to code. Entirely different mechanism, but expressing models has a lot of parallels.