ConversationReadyStateclassactor.t[4742]

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

getImpliedConvStateOVERRIDDENactor.t[4753]

my implied conversational state is my in-conversation state

inConvStateactor.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.

stateSuggestedTopicsOVERRIDDENactor.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)OVERRIDDENactor.t[4839]
handle a conversational action directed to our actor

initializeActorState ( )OVERRIDDENactor.t[4937]
initialize the actor state object

initiateTopic (obj)OVERRIDDENactor.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)OVERRIDDENactor.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