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);
Delete or comment out that new rule paragraph at the end to see how it behaves, spacing properly, 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 
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
Where are all y’all finding documentation for Threaded Conversation (or other extensions)? Is there a readme.md that I have been blind to, or are you just reading all 2400+ lines of code and going “oh, uh-huh. Got it.”?
Extensions should all have documentation at the bottom of the code – there’ll be a line saying “[Extension] ends here.”, and then after that “----DOCUMENTATION----”. They should also typically include an example or two showing how the extension works, and if you load the extension into your IDE, the Extensions tab should automatically show the docs!
EDIT: just checked to confirm that this is true for Threaded Conversations.
2 Likes
There it is on line 1236! Thank you for pointing this out so gently.
2 Likes