Listing exits...

I am considering various ways of listing exits from rooms, or at least making them more discernible to the player. I attempted to create an out of world action that lists the available directions from a location, and am wondering why the following produces only apparently the numeric IDs of the possible directions–

Posexits is a list of directions that varies. Posexits is {}. Directing is an action out of world. Understand "exits", "where are the exits" or "where is the exit" as directing. Report directing: repeat with way running through directions: let place be the room way from the location; if place is a room: add way to posexits; if posexits is {}: say "There are no discernible exits."; otherwise: say "Your exits are [posexits]."; now posexits is {}.

It works, as far as finding the directions, but obviously the numbers aren’t going to help the player. I also tried to convert ‘way’ into a text, and making ‘Posexits’ a list of texts, but that also returned numbers.

As for other methods, I’m considering the example in the manual, where you change the status line to show the possible exits, I may adapt it to special cases where I don’t want all the exits revealed. I considered using bold type to indicate exits, but going over 132 rooms, many of them outdoors–quite tedious. And I can see that what I attempted above may be superfluous as it would be simpler for the player to just read the room description.


There is a bug with the empty list, unfortunately. It gets created with the wrong type.

But in any case, I think there are easier ways to do it. Something like this would be my way:

Definition: a direction (called that way) is eligible if the room that way from the location is a room.
Report directing: 
	if the number of eligible directions is:
		-- 0: say "There are no discernible exits.";
		-- 1: say "The only way is [list of eligible directions].";
		-- otherwise: say "The possible ways are [list of eligible directions]."

(But there might be complications—things like locked doors or hidden passages, for instance.)

By the way, there is an extension for this: Exit Lister by Eric Eve.

Thanks, Jrb,

I figured it had to do with the {}. Maybe when the program encounters it, it assumes we mean numbers…?? I like your solution and I see it can be altered for special cases (putting a line ‘if the location is:’ and an enumeration of special locations under it using the ‘–’ format, writing special rules for each, then putting your ‘if’ under the final ‘-- otherwise:’).

Ultimately, I opted for listing the exits on the status line, but altered the rules in special cases–like above–such that hidden passages are not listed until exposed. Also, I don’t include exits that are incidental (eg. where you have to swing on something, as a solution to a problem, and you get one shot).

Thank you for your effort!

You can do it without using a list.

Recipe Book 6:9, example “Bumping Into Walls”. (I added a tiny map for experimentation.)

Lab is a room. Breakroom is south of Lab. Lobby is north of lab. 

Instead of going nowhere: 
	let count of exits be the number of viable directions; 
	if the count of exits is 0, say "You appear to be trapped in here." instead; 
	if the count of exits is 1, say "From here, the only way out is [list of viable directions]."; 
	otherwise say "From here, the viable exits are [list of viable directions]."

Definition: a direction (called thataway) is viable if the room thataway from the location is a room.

Thanks, Hanon.

This can also be altered for special cases, I could use a ‘if the location is:’ format under the preamble, etc.

Thank you for your input!

There’s a nice extension for that:

include Exit Lister by Gavin Lambert. … doc_1.html

There’s a confusing detail here: when you write a line like

"From here, the viable exits are [list of viable directions]."

…you’re not creating a dynamic list. This is a shortcut which iterates through a description of objects (“viable directions”) printing them out.

The difference isn’t very important, but you might have wondered.

Do the two Exit Lister extensions have similar functionality then? I haven’t explored either. From their descriptions, it looks like Gavin Lambert’s one is for automatically listing exits every turn; whereas the one I mentioned by Eric Eve’s seems to do something very close to what the OP described (implements an EXITS command).

Hanon: I think I must have had that Recipe Book example in the back of my mind when I posted earlier.

I believe the Gavin Lambert one can be set to list exits at the end of every room or only respond to an exits command. The player can also use EXITS ON and EXITS OFF to turn the list at the end on and off.

goes to his own source code to test

Yeah, you just have to set list exits to false, then it only responds to the EXITS command when the player wants it:

include Exit Lister by Gavin Lambert.

when play begins:
	Now list exits is false.
1 Like

Just a note about your original code–when you create a list variable the default variable is set to the empty list unless you specify otherwise. So you could omit the problematic line “Posexits is {}.” and it should work.

Edit: Stuff deleted. I thought that the statement in the Report rule resetting posexits to {} would be a problem. But it isn’t. (I should have realized that changing the list variable at runtime is never going to change its kind.)

I think you can also say “Truncate posexits to 0 entries” or something like that? For some reason that’s always how I empty lists out.

Thanks, guys–I was wondering about that.