The message to display when it's not possible to travel in a given direction from this room; this is either a single-quoted string or an actor action messages property (by default, it's the latter, giving a default library message).

Default posture for an actor in the location. This is the posture assumed by an actor when moving out of a nested room within this location.

Get the effective location of an actor directly within me, for the purposes of a "follow" command. To follow someone, we must have the same effective follow location that the target had when we last observed the target leaving.

For most rooms, this is simply the room itself.

our listWithActorIn table - this gets initialized to a LookupTable as soon as we need one (in listWithActorIn)

failure report we issue when we can't return to default posture

the message explaining what we must do to be travel-ready

Get the room location. Since we're capable of holding actors, we are our own room location.

our list of registered notification items

Get preconditions for travel for an actor in this location. These preconditions should be applied by any command that will involve travel from this location. By default, we impose no additional requirements.

Prefix and suffix messages for listing a group of actors nominally in this location. 'posture' is the posture of the actors. 'remote' is the outermost visible room containing the actors, but only if that room is remote from the point-of-view actor; if everything is local, this will be nil. 'lst' is the list of actors being listed. By default, we'll just show the standard library messages.

Is the actor familiar with this location? In other words, is the actor supposed to know the location well at the start of the game?

This should return true if the actor is familiar with this location, nil if not. By default, we return nil, since actors are not by default familiar with any locations.

The purpose of this routine is to determine if the actor is meant to know the location well, within the context of the game, even before the game starts. For example, if an area in the game is an actor's own house, the actor would naturally be familiar, within the context of the game, with the locations making up the house.

Note that this routine doesn't need to "learn" based on the events of the game. The familiarity here is meant only to model the actor's knowledge as of the start of the game.

Determine if the given actor has "intrinsic" knowledge of the destination of the given travel connector leading away from this location. This knowledge is independent of any memory the actor has of actual travel through the connector in the course of the game, which we track separately via the TravelConnector's travel memory mechanism.

There are two main reasons an actor would have intrinsic knowledge of a connector's destination:

1. The actor is supposed to be familiar with the location and its surroundings, within the context of the game. For example, if part of the game is the player character's own house, the PC would probably know where all of the connections among rooms go.

2. The destination location is plainly visible from this location or is clearly marked (such as with a sign). For example, if the current location is an open field, a nearby hilltop to the east might be visible from here, so we could see from here where we'll end up by going east. Alternatively, if we're in a lobby, and the passage to the west is marked with a sign reading "electrical room," an actor would have good reason to think an electrical room lies to the west.

We handle case (1) automatically through our actorIsFamiliar() method: if the actor is familiar with the location, we assume by default that the actor knows where all of the connectors from here go. We don't have any default handling for case (2), so individual rooms (or subclasses) must override this method if they want to specify intrinsic knowledge for any of their outgoing connectors.

Receive notification of travel among nested rooms. When an actor moves between two locations related directly by containing (such as from a chair to the room containing the chair, or vice versa), we first call this routine on the origin of the travel, then we move the actor, then we call this same routine on the destination of the travel.

This routine is used any time an actor is moved with travelWithin(). This is not used when an actor travels between locations related by a TravelConnector object rather than by direct containment.

We do nothing by default. Locations can override this if they wish to perform any special handling during this type of travel.

Add an item to our registered notification list for actions in the room.

Items can be added here if they must be notified of actions performed by within the room even when the items aren't in the room at the time of the action. All items connected by containment with the actor performing an action are automatically notified of the action; only items that must receive notification even when not connected by containment need to be registered here.

Show a list of exits from this room as part of failed travel ("you can't go that way").

Show the default "you can't go that way" message for this location. By default, we show a generic message, but individual rooms might want to override this to provide a more specific description of why travel isn't allowed.

Show a version of the "you can't go that way" message for travel while in the dark. This is called when the actor is in the dark (i.e., there's no ambient light at the actor) and attempts to travel in a direction that doesn't allow travel. By default, we show a generic "you can't see where you're going in the dark" message.

This routine is essentially a replacement for the cannotGoThatWay() routine that we use when the actor is in the dark.

The default "you can't go that way" message for travel within this location in directions that don't allow travel. This is shown whenever an actor tries to travel in one of the directions we have set to point to noTravel. A room can override this to produce a different, customized message for unset travel directions - this is an easy way to change the cannot-travel message for several directions at once.

The handling depends on whether or not it's dark. If it's dark, we don't want to reveal whether or not it's actually possible to perform the travel, since there's no light to see where the exits are.

Check, using pre-condition rules, that the actor is removed from this nested location and moved to its exit destination. By default, we're not a nested location, so there's nothing for us to do.

Check, using pre-condition rules, that the actor is ready to enter this room as a nested location. By default, we do nothing, since we're not designed as a nested location.

Try moving the actor into this location.

Check this object as a staging location. We're a valid location, so we allow this.

Check that the traveler is directly in the given room, using pre-condition rules. 'nested' is the nested location immediately within this room that contains the actor (directly or indirectly).

An actor is attempting to disembark this location. By default, we'll simply turn this into an "exit" command.

Dispatch the room daemon. This is a daemon routine invoked once per turn; we in turn invoke roomDaemon on the current player character's current location.

Receive notification that a traveler is arriving. This is a convenience method that rooms can override to carry out side effects of arrival. This is called just before the room's arrival message (usually the location description) is displayed, so the method can make any adjustments to the room's status or contents needed for the arrival. By default, we do nothing.

The destination for objects explicitly dropped by an actor within this room. By default, we'll return self, because items dropped should simply go in the room itself. Some types of rooms will want to override this; for example, a room that represents the middle of a tightrope would probably want to set the drop destination to the location below the tightrope. Likewise, objects like chairs will usually prefer to have dropped items go into the enclosing room.

Get any extra items in scope for an actor in this location. These are items that are to be in scope even if they're not reachable through any of the normal sense paths (so they'll be in scope even in the dark, for example).

By default, this returns nothing. Subclasses can override as necessary to include additional items in scope. For example, a chair would probably want to include itself in scope, since the actor presumably knows he or she is sitting in a chair even if it's too dark to see the chair.

The "nominal actor container" - this is the container which we'll say actors are in when we describe actors who are actually in this location. By default, this simply returns self, but it's sometimes useful to describe actors as being in some object other than self. The most common case is that normal top-level rooms usually want to describe actors as being "on the floor" or similar.

The nominal drop destination - this is the location where objects are *reported* to go when dropped by an actor in this location. By default, we simply return 'self'.

The difference between the actual drop location and the nominal drop location is that the nominal drop location is used only for reporting messages, while the actual drop location is the location where objects are moved on 'drop' or equivalent actions. Rooms, for example, want to report that a dropped object lands on the floor (or the ground, or whatever), even though the room itself is the location where the object actually ends up. We distinguish between the nominal and actual drop location to allow these distinctions in reported messages.

Get my notification list - this is a list of objects on which we must call beforeAction and afterAction when an action is performed within this room.

We'll also include any registered notification items for all of our containing rooms up to the outermost container.

The general notification mechanism always includes in the notification list all of the objects connected by containment to the actor, so objects that are in this room need not register for explicit notification.

Get the estimated height, in lines of text, of the exits display's contribution to the status line. This is used to calculate the extra height we need in the status line, if any, to display the exit list. If we're not configured to display exits in the status line, this should return zero.

Determine if the current gActor, who is directly in this location, is "travel ready." This means that the actor is ready, as far as this location is concerned, to traverse the given connector. By default, we consider an actor to be travel-ready if the actor is standing; this takes care of most nested room situations, such as chairs and beds, automatically.

Receive notification that a traveler is leaving. This is a convenience method that rooms can override to carry out side effects of departure. This is called just after any departure message is displayed. By default, we do nothing.

Get the nested room list grouper for an actor in the given posture directly in this room. This is used when we're listing the actors within the nested room as

By default, we maintain a lookup table, and store one nested actor grouper object for each posture. This makes it so that we show one group per posture in this room; for example, if we contain two sitting actors and three standing actors, we'll say something like "bill and bob are sitting on the stage, and jill, jane, and jack are standing on the stage." This can be overridden if a different arrangement of groups is desired; for example, an override could simply return a single grouper to list everyone in the room together, regardless of posture.

Make the actor stand up from this location. By default, we'll simply change the actor's posture to "standing," and show a default success report.

Subclasses might need to override this. For example, a chair will set the actor's location to the room containing the chair when the actor stands up from the chair.

remove an item from the registered notification list

as part of a room description, mention an actor in this room

describe the actor's posture while in this location

show the status addendum for an actor in this location

Provide a default description for an actor in this location, as seen from a remote location (i.e., from a separate top-level room that's linked to our top-level room by a sense connector of some kind). By default, we'll describe the actor as being in this nested room.

Receive notification that we've just finished a command within this location. This is called on the room immediately containing the actor performing the command, then on the room containing that room, and so on to the outermost room.

Receive notification that we're about to perform a command within this location. This is called on the outermost room first, then on the nested rooms, from the outside in, until reaching the room directly containing the actor performing the command.

Receive notification of travel from one dark location to another. This is called before the actor is moved from the source location, and can cancel the travel if desired by using 'exit' to terminate the command.

By default, we'll simply display the same handler we do when the player attempts travel in a direction with no travel possible in the dark (cannotGoThatWayInDark), and then use 'exit' to cancel the command. This default behavior provides the player with no mapping information in the dark, since the same message is generated whether or not travel would be possible in a given direction were light present.

Show our room description: this is the interior description of the room, for use when the room is viewed by an actor within the room. By default, we show our ordinary 'desc'.

describe the actor's posture as part of the EXAMINE description of the nested room

acknowledge a posture change while in this location

show the exit list in the status line

Receive notification that a traveler is arriving in the room. 'traveler' is the object actually traveling. In most cases this is simply the actor; but when the actor is in a vehicle, this is the vehicle instead.

By default, we set each of the "motive" actors to its default posture, then describe the arrival.

Receive notification that a traveler is about to leave the room. 'traveler' is the object actually traveling. In most cases this is simply the actor; but when the actor is in a vehicle, this is the vehicle instead.

By default, we describe the traveler's departure if the traveler's destination is different from its present location.

run the appropriate implied command to achieve our default posture

Run an implicit action, if possible, to make the current actor "travel ready." This will be called if the actor is directly in this location and isActorTravelReady() returns nil. By default, we try to make the actor stand up. This should always be paired with isActorTravelReady - the condition that routine tests should be the condition this routine tries to bring into effect. If no implicit action is possible, simply return nil.

Check the ambient illumination level in the room for the given actor's senses to determine if the actor would be able to see if the actor were in this room without any additional light sources. Returns true if the room is lit for the purposes of the actor's visual senses, nil if not.

Note that if the actor is already in this location, there's no need to run this test, since we could get the information from the actor directly. The point of this test is to determine the light level in this location without the actor having to be present.