ConversationReadyStateclass

actor.t[4742]

Superclass
Tree

Subclass
Tree

Global
Objects

Property
Summary

Method
Summary

Property
Details

Method
Details

A “ready for conversation” state. This can be used as the base class for actor states when the actor is receptive to conversation, and we want to have the sense of a conversational context. The key feature that this class provides is the ability to provide messages when engaging and disengaging the conversation.

Note that this state is NOT required for conversation, since the basic ActorState object accepts conversational commands like ASK, TELL, GIVE, and TAKE. The special feature of the “conversation ready” state is that we explicitly move the actor to a separate state when conversation begins. This is especially appropriate for states in which the NPC is actively carrying on some other activity; the conversation should interrupt those states, so that the actor stops the other activity and gives us its full attention.

This type of state can be associated with its in-conversation state object in one of two ways. First, the inConvState property can be explicitly set to point to the in-conversation state object. Second, this object can be nested inside its in-conversation state object via the ‘location’ property (so you can use the ‘+’ syntax to put this object inside its in-conversation state object). The ‘ready’ object goes inside the ‘conversing’ object because a single ‘conversing’ object can frequently be shared among several ‘ready’ states.

class ConversationReadyState :   ActorState

Superclass Tree   (in declaration order)

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

Subclass Tree  

(none)

Global Objects  

(none)

Summary of Properties  

getImpliedConvState inConvState stateSuggestedTopics

Inherited from ActorState :
autoSuggest isInitState location stateDesc

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

Inherited from TopicDatabase :
limitSuggestions suggestedTopics topicGroupActive topicGroupScoreAdjustment

Summary of Methods  

enterConversation enterFromConversation handleConversation initializeActorState initiateTopic notifyTopicResponse showGreetingMsg

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

Inherited from TravelMessageHandler :
sayArriving sayArrivingDir sayArrivingDownStairs sayArrivingLocally sayArrivingThroughPassage sayArrivingUpStairs sayArrivingViaPath sayDeparting sayDepartingDir sayDepartingDownStairs sayDepartingLocally sayDepartingThroughPassage sayDepartingUpStairs sayDepartingViaPath sayTravelingRemotely

Inherited from ActorTopicDatabase :
showTopicResponse

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

Properties  

getImpliedConvStateOVERRIDDEN

actor.t[4753]

my implied conversational state is my in-conversation state

inConvState

actor.t[4750]

The associated in-conversation state. This should be set to an InConversationState object that controls the actor’s behavior while carrying on a conversation. Note that the library will automatically set this if the instance is nested (via its ‘location’ property) inside an InConversationState object.

stateSuggestedTopicsOVERRIDDEN

actor.t[4934]

Get this state’s suggested topic list. ConversationReady states shouldn’t normally have topic entries of their own, since a ConvversationReady state usually forwards conversation handling to its corresponding in-conversation state. So, simply return the suggestion list from our in-conversation state object.

Methods  

enterConversation (actor, entry)

actor.t[4899]

Enter a conversation with the given actor, either explicitly (via HELLO or TALK TO) or implicitly (by directly asking a question, etc). ‘entry’ gives the TopicEntry that’s triggering the implicit conversation entry; if this is nil, it means that we’re being triggered explicitly.

enterFromConversation (actor, reason, oldNode)

actor.t[4815]

Enter this state from a conversation. This should show any message we want to display when we’re ending a conversation and switching from the conversation to this state. ‘reason’ is the endConvXxx enum indicating what triggered the termination of the conversation. ‘oldNode’ is the ConvNode we were in just before we initiated the termination - we need this information because we want to look in the ConvNode for a Bye topic message to display, but we can’t just look in the actor for the node because it will already have been cleared out by the time we get here.

Games shouldn’t normally override this method. Instead, simply create a ByeTopic entry and put it inside the state object; we’ll find the ByeTopic and show its message for the goodbye.

If you want to distinguish between different types of goodbyes, you can create an ImpByeTopic for any implied goodbye (i.e., the kind where the other actor just walks away, or where we get bored of the other actor ignoring us). You can also further differentiate by creating BoredByeTopic and/or LeaveByeTopic objects to handle just those cases. The regular ByeTopic will handle explicit GOODBYE commands, and the others (ImpByeTopic, BoredByeTopic, LeaveByeTopic) will handle the implied kinds.

handleConversation (otherActor, topic, convType)OVERRIDDEN

actor.t[4839]

handle a conversational action directed to our actor

initializeActorState ( )OVERRIDDEN

actor.t[4937]

initialize the actor state object

initiateTopic (obj)OVERRIDDEN

actor.t[4875]

Initiate conversation based on the given simulation object. This is an internal method that isn’t usually called directly from game code; game code usually calls the Actor’s initiateTopic(), which calls this routine to check for a topic that’s part of the state object.

notifyTopicResponse (fromActor, entry)OVERRIDDEN

actor.t[4886]

Receive notification that a TopicEntry is being used (via its handleTopic method) to respond to a command. If the TopicEntry is conversational, automatically enter our in-conversation state.

showGreetingMsg (actor, explicit)

actor.t[4783]

Show our greeting message. If ‘explicit’ is true, it means that the player character is greeting us through an explicit greeting command, such as HELLO or TALK TO. Otherwise, the greeting is implied by some other conversational action, such a ASK ABOUT or SHOW TO. We do nothing by default; this should be overridden in most cases to show some sort of exchange of pleasantries - something like this:

>bob, hello
“Hi, there,” you say.

Bob looks up over his newspaper. “Oh, hello,” he says, putting down the paper. “What can I do for you?”

Note that games shouldn’t usually override this method. Instead, you should simply create a HelloTopic entry and put it inside the state object; we’ll find the HelloTopic and show its message as our greeting.

If you want to distinguish between explicit and implicit greetings, you can create an ImpHelloTopic entry for implied greetings (i.e., the kind of greeting that occurs automatically when the player jumps right into a conversation with our actor using ASK ABOUT or the like, without explicitly saying HELLO first). The regular HelloTopic will handle explicit greetings, and the ImpHelloTopic will handle the implied kind.

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