When I use the ^createfact() macro, a fact is created.  However, when I do a :build of the topic, the fact disappears.  Is this right?

I have been trying to figure out a way to persists facts created with ^create so that it will survive ad hoc :build.  The best solution I can come up with involve exporting facts to a file after every ^createfact().  However, this seems to be an expensive way of persisting facts.  Is there a better solution? 

Thanks in advance.

I’m not sure I understand what you are saying or doing.

You can create facts using tables that are built during a :build and persist as global facts in TOPIC.

Facts created via executing createfact while conversing with a chatbot are local user facts and kept in the USERS folder as part of the user’s topic file. Doing a build does not automatically destroy them. They persist with the user identity.

You could, conceivably, write script that you tell your chatbot to save all the user facts out into a file before you do a build, and have it read in those facts on user startup.

Thanks for the reply.  The main problem I am having is that facts created using the ^createfact() disappears after a :build.  I have tried this several times and each time it disappears (from the USERS/topic_francis_harry.txt).  Thanks again.

Doesn’t happen to me… so let us consider what might be wrong.
To start… try this topic file for the bot…

topic: ~INTRODUCTIONS (~emogoodbye ~emohello ~emohowzit name here )

# matches every time on startup of a new conversation
t: (%input<%userfirstline)
Welcome to ChatScript.
createfact( john love mary)
createfact( I love john)

When you start up a user, you can open the topic file and confirm these 2 facts are at the bottom. If NOT, it means saving facts for users is disabled (maybe I left a flag wrong).  There is a param to set the limit of how many. If you have facts we dont care.

Then do a :build 1 or whatever…  reconsult that file. I don’t believe it will get touched.  Then close the app and restart it, logging in as that user. Type something to get a response. Then recheck the file. If the facts are still there, your claim is incorrect. You may be experiencing something, but not what you claim.

For simplicity, I created the test topic file: test.top

test.top ===============================
topic: ~TEST noerase repeat (~emohello)

u: (~emohello)
  ^createfact( john love mary)
  ^createfact( I love john)
  Hello back!
====================================

I then do a “:build 1”, exit ChatScript. Startup ChatScript again (local client mode) and login as a completely new user “June”.  I get the following dialogue (bot name is AIMEE):

———————————————————-
AIMEE:  I don’t know what to say.
june: > hello
AIMEE:  Hello back!
june: >
———————————————————-

I then cat the file “topic_june_aimee.txt”:

===============================
USERS/topic_june_aimee.txtMay1712

$randindex=2725
$bot=Aimee
$login=june
$token=239
$control_pre=~control
$control_main=~control
$control_post=~control
$userprompt=june: >
$botprompt=AIMEE:
0 1 1 0 # glblflags, convo start, input#, no rejoinder
~test #interesting
#end topics
hello
#`end usr
I don’t know what to say.
Hello back!
#`end bot
0 #sets flags
FACT
( john love mary )
( I love john )
===============================

Looks good so far.  The two facts are present.

Next, I do a “:build 1” from user “June”.  Cat the file “topic_june_aimee.txt” again:

===============================
USERS/topic_june_aimee.txtMay1712

$botprompt=AIMEE:
$userprompt=june: >
$control_post=~control
$control_main=~control
$control_pre=~control
$token=239
$login=june
$bot=Aimee
$randindex=2725
0 1 0 0 # glblflags, convo start, input#, no rejoinder
#interesting
#end topics
#`end usr
I don’t know what to say.
#`end bot
0 #sets flags
FACT
===============================

The fact disappears! 

Thanks for your help.

OK. sounds like you are running Linux and I’m windows… try running with a command line parameter of
userfacts=100

I am testing on Mac OS/X Lion but Linux should be identical.  I tried the following command:

./MacChatScript userfacts=100 local

I get the following command line output:
==========================================
./MacChatScript userfacts=100 localChatScript Version 2.5 64 bit
  Full dictionary code.
: words=187,279 specials=321 waste=3735 hash=65536 avgseek=1.5 maxseek=13 facts=84,734 dtext=3878492
Build0: words=66057 facts=117320 dtext=1141784 stext=0
Build1: words=8 facts=2 dtext=612 stext=1728
Currently have a substitute for fav in fav favorite
Currently have a substitute for fave in fave favorite
Currently have a substitute for accidently in accidently accidentally
Livedata: entries=10615 facts=901 dtext=178120 posrules=407
Used 47MB: dict 268,018 (31408kb) fact 202,957 (7928kb) text (5079kb) buffer (40x80000= 3125kb) user (1x7000= 6kb)
Free 139MB: dict 780,557 fact 597,043 text 115,689KB
==========================================

Where MacChatScript is the ChatScript binary I built.  Still same result.  Facts disappear after :build.

Thanks

OK. Now I’ve had the time to study this.. The issue is as follows….

When you do a build, the system internally finishes the request with a system reset… which will reset the user itself to its defaults as well, on the presumption you would want to retest now.

Had you quit, come in as a different user and done a build, your original user would have been safe.
Similarly you could do from the same run…
:switch fool
:build 1
:switch aimee

and not lose aimee.

The question is, when you rebuild, would keeping the current user untouched (who presumably has status relating to conversations in topics that may have changed) make sense as the default.  We’d have to clear some status regardless.

Of course, if the facts are NOT user specific, they can be built using tables as part of the build, and they become part of the system (until that level is rebuilt).

Thank you.  The table feature is a fantastic way to embed knowledge into the system.

Yes, if you go to RAWDATA/WORLDDATA you will see a bunch of files generating table data.

Bruce Wilcox - Jun 9, 2012:

The question is, when you rebuild, would keeping the current user untouched (who presumably has status relating to conversations in topics that may have changed) make sense as the default.  We’d have to clear some status regardless.

In the system I am building, the topics will have to be constantly enhanced with new dialogues.  That means possibly doing :build in the middle of a user’s session. I am using ^createfact a lot as a way to store user states. 

That said, I have rigged an intermediate solution: I store every topic for each user in a separate rule file.  The downside is that I have to export to the topic rule file after every ^createfact.  This seems to work pretty well and I can sleep better knowing that the user states are being ‘synced’ to files.

When running a server, you don’t build in the middle of a user’s session.  You either

1) log in as a different user, trigger a build, and then are done your turn
or
2) from a stand-alone, version, you do a new build. Then you tell the server to restart or reload itself while being an authorized user.

Bruce Wilcox - Jun 9, 2012:

When running a server, you don’t build in the middle of a user’s session.  You either

1) log in as a different user, trigger a build, and then are done your turn
or
2) from a stand-alone, version, you do a new build. Then you tell the server to restart or reload itself while being an authorized user.

I am running a Linux server.  When I need to do a :build, I use a specific user ‘admin’ and issue a ‘:build 1’.  Is this what you mean?  I am a bit confused on this issue.

sounds right.  you get to your server as a normal user would, log in as “admin” and issue a build request.

HOWEVER,  that sounds like ANYONE using your system might do that or just ask the system to crash itself.

If you want protection…. you restrict all : commands to authorized ip addresses. That’s what the authorizedIP.txt is for.
By default it is all, but you can edit it to list ip addresses on separate lines.
If you are coming from a dynamic address, first you log in via some access to the server file system to put your current ip address into that file, then you log in as a user to the chatscript server and issue the :build command.

Thanks for the quick response.  My users will be access the server through a client app and I am disallowing any system level commands.  They may be able to hack into the server and talk to it directly, so restricting IP sounds like a great idea!