Inform 7- remove supporters from room titles

When the player is on a suppoter, it says
Room Name(in the supporter) (on the other supporter).
For example, the player is in a jar, on a table, in a room.
Master’s Dorm (in the large jar) (on the table).
How do I remove the “(in the large jar)” and “(on the table)” from the description of the room?

You can do this by modifying the room description heading rule (you can figure this out by typing RULES, then entering a look command – you’ll see that rule mentioned right before the header is printed out. Then you can find the relevant rule in the Standard Rules.i7x file in the Internal\Extensions\Graham Nelson subfolder of your Inform directory). Here’s the easy way of doing that – I’ve just commented out the lines you don’t want, which is all the intermediate-level stuff:

Carry out looking (this is the new room description heading rule):
	say bold type;
	if the visibility level count is 0:
		begin the printing the name of a dark room activity;
		if handling the printing the name of a dark room activity:
			say "Darkness" (A);
		end the printing the name of a dark room activity;
	otherwise if the visibility ceiling is the location:
		say "[visibility ceiling]";
	otherwise:
		say "[The visibility ceiling]";
	say roman type;
	[let intermediate level be the visibility-holder of the actor;
	repeat with intermediate level count running from 2 to the visibility level count:
		if the intermediate level is a supporter or the intermediate level is an animal:
			say " (on [the intermediate level])" (B);
		otherwise:
			say " (in [the intermediate level])" (C);
		let the intermediate level be the visibility-holder of the intermediate level;]
	say line break;
	say run paragraph on with special look spacing.

The new room description heading rule is listed instead of the room description heading rule in the carry out looking rulebook.

Note that this is likely to be pretty confusing for the player if they’re winding up in or on top of things, though!

1 Like

Thank you. I found out that if use “instead of looking… try examining the [noun] instead” I was able to create a dummy description that removed the room description altogether.

You start off in a jar full of liquid, on a shelf, in a room, but I didn’t want you to know where you really were. I figured I might have to put you in a fake room instead and just move you when you break the jar to escape.

2 Likes

Nothing wrong with that.

1 Like

So it turns out that I had also forgotten to label the container as “closed”. By making it closed and opaque it also prevents you from trying to access items outside the container. (You need to make it lit also to avoid the darkness issue).

I’ve been trying to mess with the default activities. Apparently I can’t use check/before on the verb “Unlock” or “Lock”. The default activity is to grab a random item that you can reach and try to use that as the second noun (or the key) and give you an error message when trying to take that item.

UNLOCK JAR
(with the strange fluid)
You can’t get a grasp on the fluid.

When I want tit to say:

UNLOCK JAR
There is no mechanism on the jar to lock or unlock it.

It seems all Check and Before options take place after it trying to supply a 2nd noun and making you attempt to hold it.

You can treat that command as a mistake, which should get you what you want, so long as you never need to go back and unlock the jar later:

Understand "unlock [large jar]" as a mistake ("There is no mechanism on the jar to lock or unlock it.")

1 Like

Like Mike said, except it’s best to check the jar is visible and touchable so that you get a suitable message such as ‘You can’t see any such thing’ when you shouldn’t be able to refer to the jar (because it’s in another room, or in the dark for example)

Understand "Unlock [jar]" as a mistake ("There is no mechanism on the jar to lock or unlock it") when the jar is visible and the jar is touchable.
1 Like

Are those conditions actually needed? My understanding is that using the text token “[large jar]” should mean Inform only applies the mistake rule if the large jar is in scope, which by default should take care of the darkness and other-room issues, and some quick testing seems to confirm this. If the game’s implementing scope/reachability wackiness that would probably need to be incorporated but otherwise I think the default should work, right? From other threads I know your understanding of Inform is way deeper than mine, so I want to make sure I’m not misunderstanding something!

No, you’re right. The [jar] token will take care of scoping issues. Sorry!

1 Like