Oh man. I am now so very close. Thanks for another great idea, Blecki! It was somehow both way more complicated and way simpler than I thought to lift the Smarter Parser reparsing code and hook the implicit greetings from CF back into TC.
Right now I’m doing this (“Before printing a parser error”, so before the Understanding phase has occurred):
repeat with bystander running through probably_visible talk-ineligible people:
let temp name be indexed text;
let temp name be "[bystander]" in lower case;
if the player's command in lower case matches the regular expression temp name:
But then, obviously, the command “>ask bob about ball” won’t match a character named “Doctor Bob” (or “Dread Pirate Roberts”, for that matter—any name other than the player’s exact typed words). Is there some way to hook into the Understand machinery at the I6 level to catch any and all of the potential synonyms?
I got implicit greeting working fine without smarter parser… unfortunately I saved your latest version over it. I’m not really clear on what you’re trying to accomplish when the implicit greeting mechanism already functions as is?
At any rate I’ve been actually using it and currently am being annoyed by the disparity between questioning and actioning quips. There are cases where both forms are gramatically correct. I’m tempted to just drop the ask/tell verbs and make everything an actioning quip. EG, ‘ask about such and such is an actioning quip…’
[Actual code and terms above may be wrong. I’m using the conversation builder for most of it so I’m not familiar with the actual code]
Well, I have implicit greetings working, too. It just doesn’t accept synonyms for the potential interlocutor. I might as well paste it here.
Blecki, what sorts of naming conventions are you using? If it’s something short like “about the Countess” then actually, that might be better handled using subjects. Quips proper tend to work best with longer, more descriptive names, for various reasons.
The reason quips are divided into informative and questioning is to help generating text by the code, but also to limit which commands are sensibly understood by the parser. Technically, you could use untyped quips (“how to break into the vault is a quip”), but that tends to be ugly textually, it only accepts “>say” and “>discuss” in input, and the behavior is basically the same as performative quips anyway.
You know what, that’s needlessly confusing, and all the syntax will work identically (as far as I can tell!) so I’ve collapsed those three kinds of quips into a single trinary property of the quip kind.
Also, I do recommend reading the TC docs at some point; I think it does make the system easier to use as a whole, CB included. Threaded Conversation BETA.i7x (135 KB)
I’d like to help, but I’m having a real hard time understanding what’s wrong. Can you try outlining the problem again, perhaps by describing in a procedural way what you wish was happening? Using regular expressions is definitely not the right way to do this.
Well, here’s an example from Justin de Vesine trying to get implicit greetings working:
[code]“Quipping” by Justin de Vesine
Include Threaded Conversation Beta by Chris Conley.
Infinite Featureless Plain is a room.
The player carries a penny.
a dark figure is a man in plain.
ticket price is a subject. Understand “fare” or “cost” as ticket price.
There is a questioning quip called what the fare is. The comment is “‘What is the fare[one of][or] again[stopping]?’”.
The response is “[one of]The figure intones, ‘One penny.’ [beat] 'As per tradition. Mostly we’re tax-funded, but you can’t get away from the old standards[or]‘Still one penny[stopping].’”.
It mentions ticket price, penny.
It quip-supplies the dark figure.
It is repeatable.
test me with “ask figure about penny / talk to figure / ask figure about penny”.
Instead of thinking, follow the recap of known facts rule.[/code]
The implicit attempt fails, because it doesn’t match the player’s typed name of the character exactly to the in-code name: figure vs. dark figure.
Sorry, how’s that? This version of TC passes all of my test scripts I’ve set up, and seems to behave as it should…
Oh hey. I never realized temporary named variables of kinds of objects can’t be more specific than “object”.
Anyway no, this doesn’t work:
repeat with bystander running through probably_visible talk-ineligible people:
if the player's command includes "[bystander]":
implicitly greet the bystander;
if the bystander is the current interlocutor:
follow the relabel available quips rule;
now sp reparse flag is true;
break;
And I can’t just say “[a person]”: I need to know exactly which one, to set the interlocutor variable.
What does doing it this way get you over the way you were doing it?
Namely, what does
Understand "ask [someone talk-ineligible] about [text]" as starting a conversation with it about.
Understand "tell [someone talk-ineligible] about [text]" as starting a conversation with it about.
Starting a conversation with it about is an action applying to one thing and one topic.
Carry out starting a conversation with it about:
implicitly greet the noun;
if the noun is the current interlocutor:
follow the relabel available quips rule;
now the reborn command is "[player's command]";
now sp reparse flag is true.
I made my suggestion based on the remove interlocutor’s name rule - which I now notice is commented out. Does it not work? If it does work, you could do it in reverse - rather than cutting out the person’s name, use that to set the interlocutor.
No, seriously. This code never fired for me to implicitly greet anyone, which is why I moved to your suggestion of seeing how Smarter Parser did it, and that method worked fine.
Before printing a parser error (this is the trying harder to understand rule):
if input simple starts with "(ask|tell|discuss|say|a|t)":
if the player's command includes "[a talk-ineligible person]":
implicitly greet the bystander;
if the bystander is the current interlocutor:
follow the relabel available quips rule;
now sp reparse flag is true;
break;
I’ve actually never even looked at that rule. Emily had it commented out when I got the extension from her, I assume because the discussing it with action superseded it.
But anyway, even knowing that I7 actually has a “matched text” variable still doesn’t help me convert that snippet back into a person object. Again, I need to compare what the player typed to all possible synonyms of a given object (a person, in this case). That’s why I was asking about I6.
I can’t help with any specific problems right now except perhaps to suggest treating this extension as something that is being developed. As such, is there a reason not to put this on a shared development space, like GitHub or something like that? That way people can all see the code as it evolves, see the code without having to download it from a forum post, perhaps make changes and do pull requests?
A nice idea, but I believe the match_list is only propagated during the Asking which did you mean activity. At least, this code only shows a blank list of people, and so the part that sets the interlocutor here never runs:
Before printing a parser error (this is the implicitly greet a potential interlocutor rule):
if input simple starts with "(ask|tell|discuss|say|a|t)" and the player's command includes "[a talk-ineligible person]":
showme the list of parse-matched people;
let L be the list of parse-matched talk-ineligible people;
if the number of entries of L is positive:
let the bystander be entry 1 in L;
implicitly greet the bystander;
if the bystander is the current interlocutor:
follow the relabel available quips rule;
now sp reparse flag is true;
Well, because getting implicit greetings working properly is the last thing I want to do before wide release. This thread has gone on longer than I originally intended.
There must obviously be other differences in the version I have now, then, as it still appears to work here. Would you like it? IIRC it diverges from the version you posted last before the one you posted most recently.
I’m pretty sure I documented them all in this thread. Run a diff with this and see what else is different. (Still flawed, mind.) Threaded Conversation BETA.i7x (136 KB)
Right, I’m still not seeing any implicit greeting using this code.
Anyway I have to apologize, you were right, I posted the wrong version before.
I feel like this is getting close but still won’t compile, I hope it’s just I’m not able to get the syntax right:
Before printing a parser error (this is the implicitly greet a potential interlocutor rule):
if input simple starts with "(ask|tell|discuss|say|a|t)" and the player's command includes "[a talk-ineligible person]":
[showme the list of parse-matched people;
let L be the list of parse-matched talk-ineligible people;
if the number of entries of L is positive:
let the bystander be entry 1 in L;]
repeat with bystander running through talk-ineligible probably_visible people:
let addressee be the matched text;
if addressee matches bystander:
implicitly greet the bystander;
if the bystander is the current interlocutor:
follow the relabel available quips rule;
now sp reparse flag is true; Threaded Conversation BETA.i7x (138 KB)
It only works for asking someone about a subject/thing which a quip mentions. Actually, just changing this
Understand "ask [someone talk-ineligible] about [text]" as starting a conversation with it about.
Understand "tell [someone talk-ineligible] about [text]" as starting a conversation with it about.
to
Understand "ask [someone talk-ineligible] [text]" as starting a conversation with it about.
Understand "tell [someone talk-ineligible] [text]" as starting a conversation with it about.
Takes care of that, and implicit greetings work fine with any quip.
Can I have your entire test case? Maybe I can dig up what’s wrong with yours.
