AI Zone Admin Forum Add your forum

NEWS: Chatbots.org survey on 3000 US and UK consumers shows it is time for chatbot integration in customer service!read more..

Factual statements in the midst of a gambit
 
 

Often it’s necessary to provide information in the middle of a story without derailing the story.
Often this info could be provided in the context of various stories.


topic: ~day_sleeping (sleep)

t: My work keeps me up at night (I’m a security guard), and I tell you, sleeping in the day can be miserable.

t: Some more stuff about day sleeping

t: yet more stuff about day sleeping

topic: ~income (income money work)

t: I’m a security guard. That sure pays crappy. Blah blah

t: More about the man screwing the little guy.

==============

Of course this means ‘I’m a security guard’ gets repeated. It’d be nice if the bot remembered it’d talked about that.

My solution’s to make a topic of it:

=======


topic: ~day_sleeping (sleep)

t: My work keeps me up at night ^gambit(~guard), and I tell you, sleeping in the day can be miserable.

t: Some more stuff about day sleeping

t: yet more stuff about day sleeping

topic: ~income (income money work)

t: ^gambit(~guard) That sure pays crappy. Blah blah

t: More about the man screwing the little guy.

topic: ~guard ()

t: I’m a security guard.

========

this works well in this simple case of an included one-liner, but less well in cases where I need to remember a longer conversation, say rejoinders on t: I’m a security guard.

Is this a reasonable design pattern, and how can I handle these more complex cases?

 

 

 
  [ # 1 ]

CS tracks automatically if something has been said. It’s disabling rules.  So you could refer to a rule from multiple places and it only gets said the once.  ^reuse takes an optional argumpaent for whether or not to reuse regardless of whether it has already been disabled. And there is explicit disablement. And while CS tries to disable only the first rule generating an output, you can cancel that behavior.  So you could build a macro that:

1. does a reuse only if the rule has not been used
2. explicitly disables the rule so even if something else was already disabled this rule would get disabled.
3. perhaps turns off the “rule has been disabled already” flag

Your pattern has a similar effect and is a fine pattern for your single rule effect when used rarely. But is extravagent in designating an entire topic to a single rule if you do it often. Not that you are likely to do it hundreds or thousands of times, so you won’t really care.

As for handling more complex cases, depends on what you mean. Rejoinders on your guard gambit are automatic, they would happen directly in the guard topic and are not an issue. And additional gambits in the guard topic would also normally flow fine. Though there are issues in any topic where some gambit logically depends on the previous gambit having been said recently enough to provide context.  IE
t: I’m a security guard
t: Therefore I work at night
The second gambit doesn’t work well if you leave the topic after gambit 1 and get put back here 20 volleys later. I would tend to annotation the gambit with a macro that gates it
t: (^recent()) Therefore I work at night
where ^recent checks to see how long it’s been since this topic was last accessed and fails this rule if contectually it makes no sense. 

In the case of story topics, I generally have an alternate control script that allows single volley switches to answer any user question, but then pulls back to the story topic to drive it to completion. When you enter the story topic, a macro changes the control script, and when you complete it it restores the original one.

 

 
  [ # 2 ]

I’ve been puzzled by what the context of action of some of these things has been.

u: ALPHA ( boy ) I heard boy. ^reuse(GAMMA)  and ^reuse(DELTA) Now I’m done.
u: BETA ( girl ) I heard girl. ^reuse (GAMMA) and ^reuse(DELTA) Now I’m done.

u: GAMMA (taco) This goes in the middle.

u: DELTA (fishwich) This goes towards the end

Are you saying if the user says boy only GAMMA gets disabled? Or only ALPHA?

Sorry, I’m just oriented towards understanding the semantics of the language.

 

 

 
  [ # 3 ]

Sorry. Any rule that actually generates text going to the user will get erased. So both gamma and delta and alpha erase.

And your reuse forces output even from an erased rule. You would need ^reuse(Gamma anything) to not output if erased. ANY second argument means dont use dead rules

 

 
  [ # 4 ]

Thanks Bruce.

Going back to the ChatScript System Functions Manual,

^reuse( rule-label optional-enable optional-FAIL) - uses the output script of another
rule. The label can either be a simple rule label within the current topic, or it can be a
dotted pair of a topic name and a label within that topic or it can be a rule tag.

Whats a rule tag in this context? The term’s used in several places in the docs, but not defined.

 

 

 
  [ # 5 ]

All rules have an internal label consisting of ~topic.toplevelindex.rejoinderindex
These tags are returned by various functions like: ^getrule, ^responseruleid, %rule, %outputrejoinder, %inputrejoinder.

 

 
  login or register to react