TravelConnector

The room to which this TravelConnector leads when it is traversed

Is this connector apparent? That is, would it be apparent to an observer under normal lighting conditions, as opposed to being concealed? By default we'll suppose a TravelConnector is apparent unless it's explicitly hidden.

Should this exit be shown in the exit lister? By default we'll assumed it should be it it's visible.

A travel connector is usually open.

The posture an actor needs to be in before travelling via this connector. This will normally be standing, but this could be changed if, for example, the actor needs to crawl through this connector.

The appropriate PushTravelAction for pushing something something through a TravelConnector.

Our list of stagingLocations. We don't need to define this, in which case we'll assume the traveler needs to be directly in the room they're traveling from. If we do define this property it should contain a list of objects and/or classes and the traveler must be directly in one of them for the travel to be allowed to proceed.

If we display a message for pushing something via us, we probably don't also want the travelDesc describing the actor's travel. Game code can override if both messages are wanted when push-travelling.

Does light pass through this TravelConnector from its destination (so that it's visible in the dark even its location is dark.).

an additional TravelBarrier or a list of TravelBarriers to check on this TravelConnector to see if travel is allowed.

List of additional actors to be notified that this actor has travelled.

The number of seconds it takes to traverse this connector (in addition to any that come from the Travel action). [OBJTIME EXTENSION ONLY]

Have we been traversed by the player character? Return true if and only if we have.

A list of the actors, vehicles and pushTraverers that have traversed this TravelConnector. This is maintained by the noteTraversal(), so game code should normally treat this property as read-only.

Carry out the after travel notifications for this actor

Carry out the before travel notifications for this actor.

Method that should return true is actor is allowed to pass through this TravelConnector and nil otherwise. We allow travel by default but this could be overridden to block travel under certain conditions.

Check the travel barriers on the indirect object of the action

Check all the travel barriers associated with this connector to determine whether the traveler is allowed to pass through this travel connector.

For now, we just call the travelVia() method on the TravelConnector. Subsequentlly we might add appropriate code for the other action phases.

The TravelVia action is supplied so game code can execute a TravelVia action on a TravelConnector; there is no TRAVEL VIA command that can be issued directly by a player, but a player command may be translated into this action.

Execute the travel for this actor via this connector

Optionally specify a nested room within our destination room a traveler traveling via should be moved to on entering this room. If this returns anything that's not in our destination room it will be igonored.

If canTravelerPass returns nil explainTravelBarrier should display a message explaining why travel has been prohibited.

Our apparent destination is used by the exit lister to decide whether to colour travel in our direction as an unvisited exit. By default we just use our real destination, but game code may occasionally wish to override this to make it appear than a visited destination hasn't been visited yet, for example by returning nil.

Get the direction traveler needs to go in to traverse this connector from traveler's current location.

The room to which this TravelConnector leads when it is traversed from origin.

Get the traveler associated with this actor. Normally the traveler will be the same as the actor, but if the actor is in a vehicle, then the traveler will be the vehicle.

Test whether this TravelConnector has been traversed by traveler (which may be an actor, a vehicle, or something pushed through the TravelConnector by an actor).

no description available

A TravelConnector (or at least, the exit it represents) is visible if it's apparent (i.e. not concealed in some way) and if the lighting conditions are adequate, or if it's visible in the dark.

Does the player char know where this travel connector leads? By default s/he doesn't until s/he's visited its destination, but this could be overridden for an area the PC is supposed to know well when the game starts, such as their own house.

If the actor doing the traveling is the player character, display the travelDesc. Note that although this might normally be a simple description of the travel, the travelDesc method could also be used to carry out any other side-effects of the travel via this connector.

Display a message to say that follower is following leader in the direction of this connector.

Display a message to say that an actor is departing via this connector. On the base class the default behaviour is to describe the departure via a compass direction. The actor in question would normally be an NPC visible to the player character.

Display a message saying that this travel connector doesn't actually lead anywhere; this may be needed if our destination is nil and our noteTraversal() method doesn't display anything.

The message to display if stagingLocations is not nil and the traveler is not in one of our staging locations. It may often be better to pre-empt the display of this generic message by defining a checkReach() method on this TravelConnector if it's a physicsl one.

Check the travel barriers on this TravelConnector to ensure that travel is permitted. If so carry out the travel. If not checkTravelBarriers will have reported the reason why travel is blocked.

Modified in postures.t[586]:
Ensure the actor is in the posture needed to travel via this connector.

Carry out any side effects of travel if the traveler is the player character. Typically we might just display some text describing the travel here, but this method could be used for any side-effects of the travel. If the TravelConnector is mixed in with an EventList class then the default behaviour is to call the doScript() method here to drive the EventList.

Carrier out travel via this connector, first checking that travel through this connector is permitted for this actor.

Create a phrase describing the direction of travel through this connector (e.g. 'to the north')

If we want to vary the time to go through this TravelConnector depending on where the traveler is starting from (only really relevant for rooms), we can override this method instead. [OBJTIME EXTENSION ONLY]