AI Zone Admin Forum Add your forum

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

System within a TOPIC

I must admit that I am a little unclear on how the system variable works within a TOPIC.
I am only using it in the control script currently.

a. Are there any other special considerations for system topics? (definition below).

b. I guess they are not executed unless included in the control script?

c. Are there any $cs_prepass or $cs_control_post considerations?

d. Is repeat needed as a variable and does this introduce anything different? I am guessing the rules in a system topic are not enabled, so this variable will not apply.
(repeat: allow rules to generate output which has been output recently.)

e. is this option used in any other types of TOPICs ?

system definition:
this is a system topic. It is automatically nostay, keep.
Keep automatically applies to gambits as well.
The system never looks to these topics for gambits, (items with t: and r:).
System topics can never be considered pending (defined shortly).
They can not have themselves or their rules be enabled or disabled.
Their status/data is never saved to user files.
Topics that can never be pending are system topics.


  [ # 1 ]

I am a little unclear on your use of CS vocabulary.  There is no single system variable, there are “system variables” which work the same in any time, returning data from the system like time, current topic, etc.  A “system topic” is a topic that has the system flag on its definition. It is like any other topic except that it will never erase any rule and the next volley will never start in that topic. A system topic can have keywords just like any other and can be accessed by conversation just like any other. It is different because it cannot tell a story in successive gambits because gambits dont erase themselves after use.
There are no considerations for using them as $cs_xxxx references.  REPEAT as a topic flag is needed on any topic if you want the topic to be able to resay things recently said. It is not automatically true of a system topic.


  [ # 2 ]

Yes, you are correct, my question was regarding a “system topic”.
I appreciate your response. 
I am actively listening and repeating my understanding.

“System topics” will never erase any rules.  So they are always available.
But the next volley will not go back to this topic as a starting place, so responders are not going to work.
For example, within a system repeat topic you have
TOPIC: ~REPEATER repeat system ( )
u: ( repeat ) you are repeating yourself
    a: (~yes ) why are you repeating yourself
t: ( ) hello
r: ( ) hi

Lines a, t and r would not be triggered ever (?)
If you say “repeat” and then respond “repeat” again, line u should fire twice?

Repeat should be used for a system topic if it is intended to resay things recently said.
This is my new understanding.

I have to fix some of my code to reflect this. 
Thank you!


  [ # 3 ]

Yes, topics flagged SYSTEM always have all rules available.
Going back to a topic automatically assists responders (eg u:) but are not required if the sentence could route to the topic anyway based on keywords (but your example topic has none) or by explicit call to ^respond()  from outside. But REJOINDERS (a:) are a separate matter. Execution of the u: (repeat) rule will set the rejoinder flag, and rejoinder processing will check that location, it is not a question of whether the topic is considered currently active or not.

Since this topic is system, it will never be “the current topic” on a next volley and so no gambits would get triggered continuing, hence no t: or r:.  BUT if you explicitly call ^gambit() on it, or IMPLICITLY call it because there is code in std control script to find ANY topic with gambits to attempt to fire them if nothing else matches, it WILL come here and every volley would execute your hello rule and say that every time.

REPEAT should be used for ANY topic if it is intended to resay things recently said.


  login or register to react