Getting rid of the implied interlocutor default text

Looking for some help on an implied conversation issue.

I’d like to get rid of the default message that comes up during conversation when no second noun is provided.

For example, if there is a character named Bob in a the location with the player, and the player types “say what’s up”, the response will read “(to Bob)” and then the appropriate response. I’m trying to get rid of the “(to Bob)” part.

I don’t have any additional conversation extensions included yet.

Any suggestions you fine folks might have would be helpful.


This seems like it ought to involve the “clarifying the parser’s choice of” activity (§18.30) or the “supplying a missing noun” activity (§18.32) – which are the normal ways of dealing with this kind of thing – but in fact it does not. In this case, the message seems to be coming from a deeper part of the I6 parser that isn’t well-exposed to I7 – specifically whatever black magic Parser.i6t is doing to work out the noun in the “answering it that” action. To illustrate:

[code]Test is a room.

Lucy is a woman in Test.
Ricardo is a man in Test.

Does the player mean doing something to Ricardo: it is unlikely.

Rule for clarifying the parser’s choice of Lucy: do nothing.

Test me with “take / say hi”.[/code]Inform 7’s disambiguation correctly selects Lucy as the target of both “take” and “say hi”, but only correctly suppresses the clarification for “take”.

The best solution I can come up with is to completely detach the “say [text]” syntax from the “answering it that” action and write your own “saying” action that silently selects the correct interlocutor. Someone with a better knowledge of the I6 parser will have to comment if there’s a better way.

For what it’s worth, I don’t think this is unique to the answering it that action; it appears to happen in other cases where you have a missing noun in an Understand line with nouns reversed. That is to say, it also happens with “give” and “show”:

[code]Test is a room.

Lucy is a woman in Test.
Ricardo is a man in Test.
The player carries a mop.

Does the player mean doing something to Ricardo: it is unlikely.
Does the player mean giving the mop to Ricardo: it is unlikely.
Does the player mean showing the mop to Ricardo: it is unlikely.

Rule for clarifying the parser’s choice of Lucy: do nothing.
Rule for clarifying the parser’s choice of the mop: do nothing.

Test me with “take / say hi/ give mop/show mop/look up pie in”.[/code]


All these actions have “nouns reversed” understand lines like

Understand "give [someone] [something preferably held]" as giving it to (with nouns reversed). Understand "answer [text] to [someone]" as answering it that (with nouns reversed).

(NB “say” is a synonym for “answer”)

and I think these are all the actions in the standard rules that have “nouns reversed” understand lines.

A simple debug flag:

Before clarifying the parser's choice of something: say "Clarifying the parser's choice now!"

reveals that the Clarifying the parser’s choice activity is not running at all for the say/give/show commands.

Now here it gets hairy for me. The clarifying the parser’s choice activity is supposed to get called from PrintInferredCommand:

[code][ PrintInferredCommand from singleton_noun;
singleton_noun = FALSE;
if ((from ~= 0) && (from == pcount-1) &&
(pattern–>from > 1) && (pattern–>from < REPARSE_CODE))
singleton_noun = TRUE;

if (singleton_noun) {
	BeginActivity(CLARIFYING_PARSERS_CHOICE_ACT, pattern-->from);
	if (ForActivity(CLARIFYING_PARSERS_CHOICE_ACT, pattern-->from) == 0) {
		print "("; PrintCommand(from); print ")^";
	EndActivity(CLARIFYING_PARSERS_CHOICE_ACT, pattern-->from);
} else {
	print "("; PrintCommand(from); print ")^";


So what’s happening is that somehow in here the stuff that would trigger the BeginActivity(CLARIFYING_PARSERS_CHOICE_ACT, pattern–>from); line isn’t getting set. PrintInferredCommand is getting called by this line from within Parser Letter G:

if (inferfrom ~= 0) { PrintInferredCommand(inferfrom);

so we would need to figure out exactly where inferfrom is getting set or not set in this kind of command, and, well, this is where I give up.

I would say that prevtenet’s solution is the best, but I can’t figure out exactly how to get “say hi” to be understood as the new action while “say hi to Ricardo” gets understood as the old action. If you’re thinking of using a conversation extension it might be worth checking to see if it has a way of dealing with this.

Thanks for the suggestions. Yeah, I’ve been digging around online in both the standard rules and extensions and couldn’t find anything that specifically did what I was attempting.

I’ll play around with it some more and see what I can come up with. Maybe instead of preventing it, I can create a new action with “say”, though I’m nervous that’s going to screw up the regular answering it that action.

I’ll let you guys know if I make any progress.

Good detective work, Matt. I’ve filed a bug here.