I have used AIML program-D for many years and recently discovered ChatScript.  While I am still learning ChatScript, it strikes me as light years beyond AIML’s way of building bots.  Congradulations Bruce and many many thanks for developing such an amazing software.  With the popularity of iPhone’s Siri, I think there is a renewed interest in chatbot technologies and ChatScript is at the leading edge of this technology.

I am particularly interested in ChatScript’s reasoning ability and it’s ability to do almost rule-engine like forward and backward chaining.  That said, I have a few pressing issue in mind:

1. Fact persistence.  It seems that variables and facts do not persist over :build and :restart.  I would like to gather user’s data and states and store them permanently.  Is there anyway to do this?

2. Multiple bots.  How do I setup multiple bots?  Are there limits to the number of bots I can have?  For example, I would like to setup a bot that focuses on a particular major topic/problem domain.  As there may be potentially hundreds of major topics, I would need to setup many many bots.

3. I would like to setup informations about a bot as facts such as age, location, favorite colors.  Where would I put these facts?

4. There are some build problems with ChatScript on the linux platform.

5. When I try the auto-generate feature “:generate”, it causes segmentation fault on my mac every time.

Thanks in advance

Welcome to chatscript.

1. Fact persistence.  It seems that variables and facts do not persist over :build and :restart.  I would like to gather user’s data and states and store them permanently.  Is there anyway to do this?

:build rebuilds topic data. That means it rebuilds facts in the topics system. It doesnt touch the facts built in the dictionary, nor does it alter facts stored with users.  :restart, on the other hand, says to clear the user, so that will NATURALLY demolish his facts.  Why are you using :restart? 

2. Multiple bots.  How do I setup multiple bots?  Are there limits to the number of bots I can have?  For example, I would like to setup a bot that focuses on a particular major topic/problem domain.  As there may be potentially hundreds of major topics, I would need to setup many many bots.

Each bot needs its own initialization macro. After that, if some topics are to be restricted to specific bots, you have to use a bot restriction clause on those topics. There is no particular restriction on the number of bots.  Though I don’t know that it makes sense to have so many bots each focussing on a specific topic or problem domain. That’s an architectural discussion for which I’d need more information.

3. I would like to setup informations about a bot as facts such as age, location, favorite colors.  Where would I put these facts?

There are various ways this can be handled. You could have a “personal facts topic”, whose topic name is the same per bot but with a bot restriction so that its access is limited to the specific bot. Or you could build a table of facts, where one of the three elements is the name of the bot, so you could use a query to retrieve facts by bot. Or you could define user variables intialized differently within each bot’s initialization macro, so you could just use that variable in the answer rule that is common to all.

4. There are some build problems with ChatScript on the linux platform.
I presume #4 is actually a statement about #5.

5. When I try the auto-generate feature “:generate”, it causes segmentation fault on my mac every time.
I haven’t tried this recently. I experimented with this system but I prefer direct scripting.  I will go try it out and see what happens. May be several days before I can get to it.

Re fact persistence… I should note that in my next released build, I store the facts and user information in ONE file instead of split files. This will have as a side effect, that should I change the save format (as the next build does), user data becomes obsolete.  You could get around this by maintaining facts in your own private files. The system can read and write fact files, so you could arrange to read them in and write them out entirely from script.

I should also emphasize the value of using #! comments to document sample inputs to your rules.

This allows you to generate an abstract of your system (:abstract) as well as perform extensive unit testing on it using :verify.

Thanks for the rapid reply.  I retested facts again and, this time, for some reason, the user facts persisted through :build (as it should be). Cool.

I am a bit confused between :build and :restart. The user manual states:

:restart – makes the system reload its data files (dictionary, topics, livedata) on the fly.
This is useful if you have a live server and want to upload changes into it.

What I like to know is that if I upload a new version of my topic file, eg xxx.top, is doing a :build 1 enough?  What situation would I use :restart?

If you change a topic file, doing a :build that covers it will cause it to be updated in the executing system. If you are running a server and you did a build from a local client (same TOPIC directory), then the client would be changed, but the server UNCHANGED until a restart of the server. If you did it from the server itself, then it would be changed.

Because each user’s data contains checksums relating to each topic, every user will automatically discard user state relating to that topic ONLY. Which is what you would want. 

Doing a :build ONLY changes the data in the topic directory and causes a reload of the system doing the build.  If you had a SERVER running separately, then IT would not see the changes until it reloads also.

:restart tells the system you give that command to to reload everything and initiates a chat with the designated user. You could use that if you were connected to a server to force IT to reload changed data (dictionary, livedata, substitutes) while it was still running. (assuming you were authorized to issue that command to the server).

Whereas :reset clears the system of the current user, causing the entire user to be forgotten.