After visiting a room...


How do I phrase a rule that triggers something after the player has just entered a room, like a text being printed? I want the Room Title and description to appear and then the text to appear, but I have no clue how.


The best thing to do is to put the text at the end of your room description set off with [first time][only].

Secret Room is a room. "Here's the normal description of the room[first time].[line break]And this will only appear once[only]."

You can also use a substitution if you want to change the text that happens after the room description and have it display each time.

[code]Secret room is a room. “Here’s the normal room description.[line break][secretstuff]”

To say secretstuff:

Another way is this:

Last report going to Secret Room for the first time: say "This text will appear once only."

A technicality: this rule will print the one-time text even if the player is playing in “superbrief” mode, which suppresses all room descriptions.

Note that “…for the first time” is dangerous because it means “the first attempt”, not “the first success”. So if the player tries to go to the secret room, and is stopped by a locked door, their “first time” will have happened and the text will never be shown.

Good point.

Last report going when the player is in Secret Room for the first time: say "This text will appear, but only once."

Thank you. Hanon’s solution is good enough for what I am after.

I have to say, I am very impressed with the “Last report” rule. I searched for it in the documentation’s search and came with no results. Where is it mentioned???

It’s mentioned in 19.7 of Writing with Inform.

It’s basically a trick you have for ordering rules. You can write “first check…” to put a rule first, or “last check” to put it last.

That is, you can write a “first” or “last” rule in any rulebook.

(If there are multiple firsts or lasts, they are chained in the order that the compiler sees them. Or reverse order, I think, for “firsts”. This is an area where I7’s model doesn’t scale well.)


To make sense of this, I think the way it works is that I7 goes through every “put this rule here” statement and executes them in source code order. So if you have:

First report going {this is the third rule): [blah blah] First report going (this is the second rule): [blah blah] First report going {this is the first rule): [blah blah]

what happens is that the compiler encounters the third rule, and puts it first in the report going rulebook. Then it encounters the second rule, and puts that first–namely in front of the third rule, which has already been placed. Then it encounters the first rule, and puts it in front of the second and third rules. So the order winds up first, second, third, the opposite of the source code order.

This is also how “listed before/listed after” declarations work; they’re gone through in order, which means that if you have more than one your first one might not be respected by the time the last one is done. See here. Which is, I guess, I7’s model not scaling well.

I believe they stack in code order. Meaning the compiler will read…

[code]First check … (this is rule 1)…

First check… (this is rule 2)…[/code]

by putting rule 1 first in the rulebook, and then putting rule 2 first in the rulebook, bumping rule 1 down. So you’d end up with rule 2 checked first, then rule 1–seemingly backward from what the author intends.

That’s my hypothesis. I could, as in most cases, be delusional.

By that reasoning,

[code]Last check … (this is rule 1)…

Last check… (this is rule 2)…[/code]

would put rule 1 last, then rule 2 last, keeping them in correct “intentional” order.

Your explanations (matt and HanonO) are correct. I still am never going to remember which way the first/last prioritization runs, because it is not a meaningful piece of language design.