A TravelConnector is an object that can be attached to the directional exit property of a room to facilitate (or optionally block) travel in the associated direction and carry out any side-effects of that travel. A TravelConnector may be used as an abstract object to implement travel, or a subclass of TravelConnector such as Door, Passage, StairwayUp or StairwayDown may be used to represent a physical object via which travel occurs. The Room class also inherits from TravelConnector.
Whether the base TravelConnector class or one of its subclasses is used, travel is carried out via a TravelConnector by calling its travelVia() method.
Modified in objtime.t[348]:
Modifications to TravelConnector for the OBJTIME EXTENSION. The purpose of these modifications is to allow different TravelConnectors to take different amounts of time to traverse.
Modified in postures.t[577]:
If the Room is illuminated, display its ordinary room title, followed by the actor's immediate location if it's not the Room. If the Room is in darkness, use the darkName instead of the roomTitle.
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.
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.
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.
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.
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.
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.
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.
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 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).
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 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.
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]
Adv3Lite Library Reference Manual Generated on 26/02/2025 from adv3Lite version 2.2