TopicResolverclass | action.t[6332] |
Superclass Tree | Subclass Tree | Global Objects | Property Summary | Method Summary | Property Details | Method Details |
class
TopicResolver : Resolver
TopicResolver
Resolver
object
TopicResolver
ConvTopicResolver
TActionTopicResolver
isGlobalScope
qualifierResolver_
topicProd
Inherited from Resolver
:
action_
actor_
equivs_
isSubResolver
issuer_
scope_
whichMessageObject
whichObject
construct
filterAmbiguousNounPhrase
filterPluralPhrase
filterPossRank
getAll
getAllDefaults
getDefaultObject
getPossessiveResolver
getQualifierResolver
noMatch
noMatchPoss
noVocabMatch
objInPhysicalScope
objInScope
packageTopicList
resetResolver
resolveTopic
resolveUnknownNounPhrase
Inherited from Resolver
:
allowAll
cacheScopeList
filterAll
filterAmbiguousEquivalents
getAction
getPronounDefault
getRawPronounAntecedent
getReflexiveBinding
getScopeList
getTargetActor
matchName
resolvePronounAntecedent
selectIndefinite
withGlobals
isGlobalScope OVERRIDDEN | action.t[6405] |
qualifierResolver_ | action.t[6385] |
topicProd | action.t[6531] |
construct (action, issuingActor, targetActor, prod, which, qualifierResolver) OVERRIDDEN | action.t[6333] |
filterAmbiguousNounPhrase (lst, requiredNum, np) OVERRIDDEN | action.t[6459] |
It is almost always undesirable from a user interface perspective to ask for help disambiguating a topic phrase. In the first place, since all topics tend to be in scope all the time, we might reveal too much about the inner model of the story if we were to enumerate all of the topic matches to a phrase. In the second place, topics are used in conversational contexts, so it almost never make sense for the parser to ask for clarification - the other member of the conversation might ask, but not the parser. So, we'll always filter the list to the required number, even if it means we choose arbitrarily.
As a first cut, we prefer objects that are physically in scope to those not in scope: if the player is standing next to a control panel and types "ask bob about control panel," it makes little sense to consider any other control panels in the simulation.
As a second cut, we'll ask the actor to filter the list. Games that keep track of the actor's knowledge can use this to filter according to topics the actor is likely to know about.
filterPluralPhrase (lst, np) OVERRIDDEN | action.t[6503] |
filterPossRank (lst, num) OVERRIDDEN | action.t[6431] |
getAll (np) OVERRIDDEN | action.t[6527] |
getAllDefaults ( ) OVERRIDDEN | action.t[6528] |
getDefaultObject (np) OVERRIDDEN | action.t[6515] |
getPossessiveResolver ( ) OVERRIDDEN | action.t[6389] |
getQualifierResolver ( ) OVERRIDDEN | action.t[6388] |
noMatch (action, txt) | action.t[6523] |
noMatchPoss (action, txt) | action.t[6524] |
noVocabMatch (action, txt) | action.t[6522] |
objInPhysicalScope (obj) | action.t[6417] |
Note that this isn't part of the basic Resolver interface. It's instead provided as a service routine for our subclasses, so that they can easily determine the physical scope of an object if needed.
objInScope (obj) OVERRIDDEN | action.t[6399] |
packageTopicList (lst, match) | action.t[6365] |
resetResolver ( ) OVERRIDDEN | action.t[6352] |
resolveTopic (lst, requiredNum, np) | action.t[6478] |
This default base class implementation simply creates a resolved topic list with the whole set of possible matches undifferentiated. Subclasses for specialized actions might want to differentiate the items in the list, based on things like the actor's knowledge so far or what's in physical scope.
resolveUnknownNounPhrase (tokList) OVERRIDDEN | action.t[6489] |