Hello!

So how can my responder catch input which was written in multiple sentences?
Thanks!

that part is easy.  Your bot defines a topic to call to “preprocess”. A topic to call FOR EACH SENTENCE of input. And a topic to call for postprocess. You will get called for each sentence. The question SHOULD BE what you want to do on each sentence. Respond to each? hold up? what?

hhmmm still don’t get it.  I’ve played with nofail, retry, read the esoteric example and now tried to follow through :postprocess.
The question is, I want to catch and respond to the sentences only after all are input, as if it were one command. The sentences, if input independently, would be managed by different responders.

Suppose the chatbot says:
” do you have any pets”
and the user says:
” Yes.  I have a dog.”

You get 2 sentences from the user without any interference from chatscript. You MIGHT decide that you got a “yes”, but there is another sentence pending and simply ignore the yes.

Of course, if the user says:
“Yes. Do you like dogs.”

you can’t ignore the first sentence.  So what we have to look at is your specific use cases you are trying to address. Then MAYBE we can decide how to handle multiple sentences on input, sometimes FORCED by chatscript because it breaks off interjections into their own sentence.

You can, for example, early on, detect interjections, record them onto variables, then do if %more is true, something like
^fail(SENTENCE) and go back and process the next input.

I have some results of test runs and most requests to the bot are written as multiple sentences, e.g. statement followed by question. In such a case the statement by itself could be picked up by other topics. I think to recognize interjections would require as many, as respective rules…
From your example, if I recognize sentence 1 and set %more is true, I’d have to be really sure I have the 2nd sentence or more will stay forever true. Right?
Can I read-in the next sentence without leaving the current rule?
—
A similar question I previously had:
I have different responders which call an outputmacro, then expect a rejoinder. Each responder contains overlapping rejoinders, as in,
u: s1
  create variables
  ^om()
  a: A
  a: B
u: s2
  create same variables from different input
^om()
  a: A
  a: B

Any way I could have rejoinders follow an outputmacro independent of who called it?
It seems the method above, of fail and goto responder where $more = true, would have less repetitive code than the macro… Or is there a more elegant way?

Thanks!

First, %more is a system variable. You don’t set it. It tells YOU there is another sentence pending from the user still.

The current version cannot read in the next sentence while you are processing the first. A version due up shortly can.

Macros are only part of a rule, hence cannot have rejoinders AFTER them. But you can ^reuse things.

u: s1 create variables ^reuse(COMMON)
u: s2 create same variables from different input ^reuse(COMMON)
u: COMMON (? !?) ^om()
  a: A
  a: B

Oh, yeah, I took it as %whatever.

Allright.

I wanted to use ^reuse, but how to have COMMON never match any input and only execute when ^reused? What would (? !?) be? I had missed playing with variables in such way, but is there a straight way of doing it?

the pattern (? !?) is one of many that CANNOT match. It tests if the input is both a question and not a question.

ha! another missed system-defined-answer.
Thank you!

It’s hard to know all the ramifications and capabilities of “simple” things.

By the way, the rationale here is as follows.

One must always trade cpu and memory in some way. Chatscript uses memory to make pattern matching cheap, reducing the cost of processing a single sentence. Making available multiple sentences at a time becomes both expensive in space AND complex in writing rules for (though I might do it someday for 2 sentences at a time, the most common case).

The system breaks off interjections because the user can do so. Yes, I love apples and Yes. I love apples. are semantically equivalent and you don’t want to try to write patterns that can handle both forms. Hence the system makes it a canonical requirement that they are broken apart.

Making available multiple sentences at a time becomes both expensive in space AND complex in writing rules for (though I might do it someday for 2 sentences at a time, the most common case).

That’s what initially killed my bot in the chatbot battles. Got that fixed now though. As a side note, it doesn’t have to make rule writing that much more complex than writing for a single sentence.

Hi,

Can you elaborate a bit on how to do this? My crude attempt at removing ~emohello and reprocessing the remaining sentence seems to fail (example input “Hi! I have a dog”). I guess that is because _0 is empty. What would be the correct way of doing this?

topic: ~DOG ( dog )
s: ( I have a dog )
  Woof!

topic: ~INTRODUCTIONS (~emogoodbye ~emohello ~emohowzit name here )
t: (%input<%userfirstline)
      noerase() 
      Welcome to ChatScript.

u: ( ~emohello _* >)
  You said _0.
  ^input(_0)
  ^fail(sentence)

You only see 1 sentence at a time. PERIOD.  so you cant trap ~emohello and another sentence using a single pattern.
Normally the system will see the first sentence (~emohello) and generate a response. It will then see the second sentence and generate a 2nd response.  This would be the “normal” or “default” way of doing things.  When you want something different to happen, you have to code your control script or your regular script differently.

The question is…. what do you want to do. 
If the user says Hello! I have a dog.
What output do you want out of your chatbot. Do you want it to reply:
Hello back.  That’s nice that you have a dog.

Or ignore hello or ignore the dog or what?

first, I am going to release a tiny update probably tonight to be more efficient about it.  Here is an example of how I would use it….

The issue is a user answering the question “do you have any pets” might say:
Yes.
Yes, I have a dog.
Yes. I have a dog.

The 2nd 2 inputs are the same to chatscript, because it breaks off the interjection into its own sentence.
If the user says just yes, you want to ask what kind. If the user is already going to answer that question you don’t want to ask it.

t: Do you have any pets
  a: (~yes)  refine()
      b: (%more)  NextInput() refine()
        c: (~pets)  ….. react to pet
        c: () ^retry(SENTENCE)  # return to try input from scratch
      b: () What kind do you have?
          c: (~pets) …. react to pet

The current coding would require
        c: (_*)  input(‘_0)  fail(SENTENCE)
but that forces the system to receive the new input again and reanalyze it again.  Since the analysis done by NextInput is still valid, this is wasteful and hence ^retry now takes what kind of thing to retry and for sentence doesnt redo the prep work.  This retry FAILS all the way back to initial processing of the sentence then comes in “as though it were doing this second sentence normally”.

Thanks for the help, I’ll try this.