AccompanyingInTravelStateclass

“Accompanying in-travel” state - this is an actor state used when an actor is taking part in a group travel operation. This state lasts only as long as the single turn - which belongs to the lead actor - that it takes to carry out the group travel. Once our turn comes around, we’ll restore the actor to the previous state - or, we can set the actor to a different state, if desired. Setting the actor to a different state is useful when the group travel triggers a new scripted activity in the new room.

class AccompanyingInTravelState : ActorState

Superclass Tree (in declaration order)

AccompanyingInTravelState
ActorState
TravelMessageHandler
` object[ActorTopicDatabase](../object/ActorTopicDatabase.html) [TopicDatabase](../object/TopicDatabase.html) object`

Subclass Tree

AccompanyingInTravelState
GuidedInTravelState

Global Objects

(none)

Summary of Properties

leadActor nextState

Inherited from ActorState :
autoSuggest getImpliedConvState isInitState location stateDesc stateSuggestedTopics

Inherited from ActorTopicDatabase :
askForTopics askTopics commandTopics giveTopics initiateTopics miscTopics showTopics specialTopics tellTopics

Inherited from TopicDatabase :
limitSuggestions suggestedTopics topicGroupActive topicGroupScoreAdjustment

Summary of Methods

construct initiateTopic sayArrivingLocally sayDeparting sayDepartingDir sayDepartingDownStairs sayDepartingLocally sayDepartingThroughPassage sayDepartingUpStairs sayDepartingViaPath specialDesc takeTurn

Inherited from ActorState :
activateState afterAction afterTravel arrivingTurn arrivingWithDesc beforeAction beforeTravel deactivateState distantSpecialDesc endConversation getActor getNominalTraveler getSuggestedTopicList getTopicOwner handleConversation initializeActorState justFollowed notifyTopicResponse obeyCommand remoteSpecialDesc showSpecialDescInContents specialDescListWith suggestTopicsFor

Inherited from TravelMessageHandler :
sayArriving sayArrivingDir sayArrivingDownStairs sayArrivingThroughPassage sayArrivingUpStairs sayArrivingViaPath sayTravelingRemotely

Inherited from ActorTopicDatabase :
showTopicResponse

Inherited from TopicDatabase :
addSuggestedTopic addTopic addTopicToList compareVocabMatch findTopicResponse handleTopic removeSuggestedTopic removeTopic removeTopicFromList showSuggestedTopicList

Properties

leadActor

actor.t[5377]

the lead actor of the group travel

nextState

actor.t[5383]

the next state - we’ll switch our actor to this state after the travel has been completed

Methods

construct (actor, lead, next)OVERRIDDEN

actor.t[5366]

no description available

initiateTopic (obj)OVERRIDDEN

actor.t[5413]

initiate a topic - defer to the next state

sayArrivingLocally (dest, conn)OVERRIDDEN

actor.t[5454]

Describe local travel using our standard departure message as well. This is used to describe our travel when our origin and destination locations are both visible to the PC; in these cases, we don’t describe the departure separately because the whole process of travel from departure to arrival is visible to the PC and thus is best handled with a single message, which we generate here. In our case, since the “accompanying” state describes even normal travel as though it were visible all along, we can use our standard “departing” message to describe local travel as well.

sayDeparting (conn)OVERRIDDEN

actor.t[5435]

Override our departure messages. When we’re accompanying another actor on a group travel, the lead actor will, as part of its turn, send each accompanying actor (including us) on ahead. This means that the lead actor will see us departing from the starting location, because we’ll leave before the lead actor has itself departed. Rather than using the normal “Bob leaves to the west” departure report, customize the departure reports to indicate specifically that we’re going with the lead actor. (Note that we only have to handle the departing messages, since group travel always sends accompanying actors on ahead of the main actor, hence the accompanying actors will always be seen departing, not arriving.)

Note that all of these call our generic sayDeparting() method by default, so a subclass can catch all of the departure types at once just by overriding sayDeparting(). Overriding the individual methods is still desirable, of course, if you want separate messages for the different departure types.

sayDepartingDir (dir, conn)OVERRIDDEN

actor.t[5437]

no description available

sayDepartingDownStairs (conn)OVERRIDDEN

actor.t[5441]

no description available

sayDepartingLocally (dest, conn)OVERRIDDEN

actor.t[5455]

no description available

sayDepartingThroughPassage (conn)OVERRIDDEN

actor.t[5438]

no description available