Threaded Conversation by Chris Conley

Oh, I’ve solved it! I have Windows 7 & 8.1 on two computers, and the problem is IE caching Inform’s downloads.

[spoiler]I was very thoroughly making sure there were no copies of “Threaded Conversation.i7x” hiding out somewhere on the computer, and there weren’t. Then I extended my search to all extensions, so searching my entire computer for “.i7x”, and found that extensions get cached when Inform downloads them, and apparently mine never get cleared out.
Deleting “Threaded%20Conversation[1].i7x” out of C:\Users\Lucy\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\21C8Z3Y0" allowed Inform 7 to download the new version, instead of forever using the cached one.

I do use IE occasionally, but apparently not enough that it can be trusted to clear it’s cache.
I don’t see this issue on the bug tracker, so I’ll report it when my signup goes through unless someone else wants to first.
I did update to the latest Inform front end dated 23rd February 2018 during troubleshooting, so it’s still a current issue (previously I had July 2017).[/spoiler]

Thanks for the update!

In example “Not So Simple” if you type:

ask barmaid about rumors
ask wanderer about rumors

after second command
“the current interlocutor” is changed to wanderer, which is reflected in the status bar. - that’s ok
Action [the wanderer discussing whether she’s heard the stories] is executed - this is strange because quip “whether she’s heard the stories” quip-supplies the barmaid.

Is this a bug or am I missing something obvious?

full transcript below:

[spoiler]Not So Simple
An Interactive Fiction
Release 1 / Serial number 180912 / Inform 7 build 6M62 (I6/v6.33 lib 6/12N) SD
Identification number: //16C3AD9B-8859-4C21-A8CE-314BFDB1DB74//
Interpreter version 0.5.2 / VM 3.1.2 / Library serial number 080126
Standard Rules version 3/120430 by Graham Nelson
Threaded Conversation version 7/180807 by Chris Conley (modified from Threaded Conversation by Emily Short and based on Alabaster by Emily Short, et. al.)
Conversation Framework version 12 by Eric Eve
Epistemology version 9 by Eric Eve

ask barmaid about rumors
“Where I come from, over the black hills there, they say that men this side of the mountain live as old as Methuselah,” you remark. “They say the secret of eternal life is here.”

“Oh, do they?” she says, sweeping crumbs of cheese and crusty bread into her hand. “The oldest codger around these parts is old Garrick, and I wouldn’t put him beyond his four-score and ten.”

You could ask where Garrick lives, ask where the barmaid comes from or ask whether she’s heard the stories.

actions
Actions listing on.

ask wanderer about rumors
[starting a conversation with the wanderer about “about rumors”]
[(1) saying hello to the wanderer]
[(1) saying hello to the wanderer - succeeded]

[starting a conversation with the wanderer about “about rumors” - succeeded]

[discussing whether she’s heard the stories]
“Have you heard any stories of long-living men?” you press her.

[discussing whether she’s heard the stories - succeeded]

[the wanderer discussing whether she’s heard the stories]
She pinches her lips and scrubs at a circle-shaped stain on the table before her. “If you’re a fool come looking for a spring of life or a vein of immortal gold buried in the black hills, you’d do better to go back home where you come from.”

[the wanderer discussing whether she’s heard the stories - succeeded]

You could ask whether the rumors tell truly.[/spoiler]

Huh. That’s interesting. That does look like a bug.

At first glance, I suspect it’s because whether she’s heard the stories indirectly-follows whether the rumors tell truly, and I bet the mechanism that parses the conversation action while the current interlocutor is not the person quip-supplied by the quip in question doesn’t test quite as many conditions as the full-fledged system does. Note that the wanderer responds correctly if you ask him about the rumors after you’re already talking to him. Let me investigate further.

I’ve been experimenting with weakly-phrased quips, and I’ve noticed that the paragraph always runs on after the reply is printed. This results in the suggestions or even the prompt ending up in the same paragraph as the reply.

I had a look at the rule that prints the reply, and I’m confused by that as well.

Report someone discussing something (this is the interlocutor's reply rule):
[	This is a report, rather than a carry out rule, so that in theory characters can discuss things in another room, exchanging information behind the player's back.	]
[	It also means that we can override the report rule without messing up any of the other quip-machinery accounting that needs to happen during the action.	]
	if the noun provides the property reply:
		say "[reply of the noun]" (A);
		if break after reply is true and the noun is strongly-phrased, say paragraph break;
		if the noun is weakly-phrased, say " [run paragraph on]" (B);
		now break after reply is false. [Even if one reply recursively induces this character to perform another immediately after, we still only want to print one paragraph break at the end.]

The comments suggest that it is trying to print a paragraph break only after the last reply, but the code would seem to put the paragraph break after the first reply. Also, since break after reply is a global variable that is set to true when setting action variables, it isn’t clear to me when it would ever be false.

2 Likes

I think I remember this giving me trouble. Line spacing is always tricky to get right on I7 even when you’re not trying to hack things at this deep level.

I still need to look into that indirectly-following problem too.

So, I believe this was my solution to get weakly-phrased quips to work at all, properly folding the end of the interlocutor’s reply into their next change of subject. The last example, Blackened Blue, shows how they interlock with a character who has his own set of queued quips.

Weakly phrased quips are really only intended to be used when the NPC has their own queue of quips they want to get through. If not, only strongly-phrased quips (as all quips are, by default) should be used.

If I could, I’d like to make that clearer in the extension documentation:

There are a few properties of quips we can define to control this behavior. By default, a quip is considered "strongly-phrased"; we may mark it "weakly-phrased" instead if its reply text is merely a transitional phrase or minor comment, before the character then moves on to her topic of interest, so that the replies of each quip can be folded into the same paragraph. This property generally works best if the reply itself is not written with a grounding beat of its own at the end. (Note that if a weakly-phrased, dead-ended quip is followed by a character's queued change of subject, the prevent talking heads activity will be bypassed entirely.) Note, however, that this means that weakly-phrased quips should only be used when the interlocutor has a queue already stocked with quips that she is itching to get to.

How does that look?

As that code shows, break after reply is only set false after a character says the reply of a quip in a turn. So, in a turn where multiple strongly-phrased quips get discussed and are wrapped together in a single paragraph, only one paragraph break will be printed, rather than two or more in a row. (Weakly-phrased quips run the paragraph on, after all, so break after reply has nothing to do with them.)

This usually only happens if quips are triggered in a nonstandard way. The distracted reply rule mini-example in the documentation (the one involving the Shadows event) shows a case where the quips can cause paragraph breaks to pile up, if you comment out that line setting break after reply to false in the extension.

slightly expanded sample code
Include Threaded Conversation v8 by Chris Conley.

There is room. Lily is a woman, here. The player carries a book.

it was horrible finding Lily poisoned is an informative quip. It quip-supplies Lily. 
The printed name is "it was horrible finding her poisoned".
The comment is "'It was horrible finding you poisoned.'"
The reply is "Her eyes go wide."

Lily looks well is an informative quip.
The comment is "'You look very well, Lily,' you say, winking.".
The reply is "'Why, thank you!' Lily replies.".

whether it will rain is a questioning quip.
The comment is "'What do you think of the weather?' you ask. 'Will it rain?'"
The reply is "'I really don't know,' says [the current interlocutor]."

The distracted reply rule is listed instead of the prepare a reply rule in the carry out discussing rulebook.

This is the distracted reply rule:
	 if Shadows is happening:
		 if the person asked is not the player, make no decision;
		 if the noun is not quippishly-relevant,
			 queue act-distracted as immediate obligatory;
		 otherwise queue noun as immediate obligatory;
	 otherwise:
		 queue noun as immediate obligatory;

 act-distracted is an NPC-directed performative quip. To continue is a verb. To ignore is a verb. To show is a verb.
 The reply is "[Regarding the person asked][They] [one of][continue] [possessive] own line of thought[or][ignore] your remark[or][are] looking somewhat past your head[or][don't] [show] signs of following what you just said[at random]. [run paragraph on][awkward segue]"

 To say awkward segue:
	if any conversation is queued for the person asked,
		perform the next queued conversation for the person asked;

 Shadows is a scene. Shadows begins when Lily recollects it was horrible. Shadows ends when the player does not have the book.
 
 When shadows begins: queue she-hates.
 
 she-hates is an NPC-directed quip. It quip-supplies Lily. 
 The reply is "'I hate you,' she says quietly.[run paragraph on]"

[The whitespaced interlocutor's reply rule is listed instead of the interlocutor's reply rule in the report discussing rulebook.
Report someone discussing something (this is the whitespaced interlocutor's reply rule):
[	This is a report, rather than a carry out rule, so that in theory characters can discuss things in another room, exchanging information behind the player's back.	]
[	It also means that we can override the report rule without messing up any of the other quip-machinery accounting that needs to happen during the action.	]
	if the noun provides the property reply:
		say "[reply of the noun]" (A);
		if break after reply is true and the noun is strongly-phrased, say paragraph break;
		if the noun is weakly-phrased, say " [run paragraph on]" (B);
transcript without setting that variable false

Delete or comment out that new rule paragraph at the end to see how it behaves, spacing properly, with the current rule:

transcript with the current rule

EDIT: But, hmm. Maybe that act-distracted quip should actually be weakly-phrased. That would fix this whole problem. I might try cutting break after reply entirely for the next release and see if anything breaks.

2 Likes

That change in the documentation seems reasonable. Another condition worth mentioning is that no third parties should have queued quips, either, since they might appear between the weakly-phrased quip and the next queued quip.

Thanks for the example. I hadn’t considered the possibility of performing a queued quip while replying, and now I see what that code is intended to do. It seems like it would only work when [awkward segue] comes last in the reply for act-distracted, though.

It’s a pity there’s no way to, say, print a paragraph break only when the last thing printed was not a paragraph break. That would simplify this logic immensely.

Yes, and part of the problem is the break-printing rules in I7 are fairly obscure, some of them even buried in the I6 layer. I hope the code release at the end of summer can help make things more accessible.

I think I’ve identified the issue. When you switch interlocutors with a command like “ask (someone) about (something)”, the quips get relabeled but any listed-plausible quips remain listed.

This particular problem goes away if you add the rule below to Not So Simple, but this could probably be handled elsewhere.

Before reading a command when tc reparse flag is true:
	now every quip is unlisted-plausible.

I figured this out while I was trying to make “talk to (someone) about (something)” work similarly “tell/ask (someone) about (something)”. (I kept trying to use it, so figured I might as well add it.) I had assumed that the tc reset flag somehow canceled the current action and returned to parsing the command, but it actually prevents printing the prompt, so that the next turn gets the same command.

This has a few surprising effects: the turn counter advances by 2, and the every turn rules (including the conversation reply rules) will run before and after the discussion action. So, if a character has queued conversation, they may say it after the player enters “tell X about Y” but before the discussion happens.

For example,

Code
The Lab is a room.

Alice is a woman in the Lab.
Bob is a man in the Lab.

foo is an informative quip.
The comment is "'Foo,' you say."
The reply is "'Foo?', Alice replies[casually queue bar]."
It quip-supplies Alice.

foofoo is an informative quip.
The comment is "'Foofoo,' you say."
The reply is "'Foofoo?' Alice replies."
It quip-supplies Alice.
It indirectly-follows foo.

bar is an npc-directed quip.
The reply is "'Bar!' says Alice."
It quip-supplies Alice.

baz is an informative quip.
The comment is "'Baz,' you say."
The reply is "'Quux,' Bob replies."
It quip-supplies Bob.

test me with "tell alice about foo / tell bob about baz".
Transcript
>test me
(Testing.)

>[1] tell alice about foo
"Foo," you say.

"Foo?", Alice replies.

You could say foofoo.

>[2] tell bob about baz
"Bar!" says Alice.

"Baz," you say.

"Quux," Bob replies.
1 Like

Thanks! I probably can’t look into this for a bit but this will be a good place to start.

Hi there. I’m using Threaded Conversation but having trouble with the availability rules. I want to restrict a quip so that it’s only available if a particular scene is running.

This doesn’t work:

An availability rule for available jobs:
	if interview scene is not happening, it is off-limits.

Inform simply doesn’t understand “is not happening”.

So the obvious thing to do is to say that if scene x is happening, it’s OK, but otherwise it’s off-limits. But unfortunately the documentation only shows examples of restricting a quip by declaring it off-limits. What is the opposite phrase to off-limits?

An availability rule for available jobs:
	if interview scene is happening, it is <???>;
        otherwise it is off-limits;
1 Like

My first thought was to make a work-around by introducing a new boolean property as a proxy for “not happening”, like this:

A person can be interviewed-at-the-moment. [default is: not]

When Interview begins:
	now the player is interviewed-at-the-moment.
	
When Interview ends:
	now the player is not interviewed-at-the-moment.

An availability rule for available jobs:
	if the player is not interviewed-at-the-moment, it is off-limits.

That should work, even though it would be a bit cumbersome, especially if you needed to expand it for other scenes and properties.

But thankfully, that’s not necessary, because the opposite of “off-limits” is actually “available”. It’s easy to overlook in the documentation, but see the beginning of “Section: The availability rules” in the extension’s docs:

So the following should work:

An availability rule for available jobs:
	if Interview is happening, it is available;
	otherwise it is off-limits.

Hope this helps :slight_smile:

2 Likes

Available! D’oh! I was so busy trying to think of what the opposite of something being “off limits” could be (within limits, within bounds, in range, permitted) that I just went down the rabbit hole! Thanks!

Found a potential typo. It’s in line 190 on Github, in Volume One, Book 3, Part Two:

This is the recap of known facts rule:
	if the player does not know at least one fact:
		say "[We] [haven't] discovered much yet." (A) instead;
	say "[We] [think] back over the things that [we] [know]: [line break]  " (B);
	repeat with item running through facts:
		if the player knows the item:
			say "[summary of the item][line break]  (C)";

That (C) should be outside of the quotes, to mark it as a named rule response (and prevent it from being printed every time the rule is invoked), yes?

4 Likes

Sure looks like a typo. I committed a fix to the Friends repo – good catch.

1 Like

Nice catch.

Whoa, the version of the extension on Herokuapp is Version 3. Not sure what that is or how that happened…

I suppose I might as well update the github with my own official Version 8, which fixes a couple more issues.

2 Likes

It would be good to email it to @markm too, so it could go into the Inform 7 Public Library …

1 Like

I’ve downloaded version 8, and jsyk the ‘ends here’ sentence causes a compilation error. It doesn’t like that it says “Threaded Conversation v8 ends here” when the ‘begins here’ sentence just calls it “Threaded Conversation.”

1 Like

Whoops. Yeah, keeping multiple versions of an extension tends to make these errors crop up.

Thanks, I’ve submitted a new fix for this to Mark.

3 Likes

The new version should be up on the Public Library now - please let me know if you see any issues

2 Likes