AccompanyingInTravelState class | actor.t[5365]

"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`
`TopicDatabase`
`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

`sayDepartingUpStairs (conn)`OVERRIDDEN | `actor.t[5440]`

no description available

`sayDepartingViaPath (conn)`OVERRIDDEN | `actor.t[5439]`

no description available

`specialDesc ( )`OVERRIDDEN | `actor.t[5389]`

Show our "I am here" description. By default, we'll use the arrivingWithDesc of the *next* state object.

`takeTurn ( )`OVERRIDDEN | `actor.t[5392]`

take our turn

TADS 3 Library Manual
Generated on 5/16/2013 from TADS version 3.1.3