I am working on a project that involves human users interacting in a virtual world with several virtual agents.  I am looking at using ChatScript to handle the dialog for these agents since I can define several different personalities within the same server.

One requirement for my system is that the people will be using this system for a long time (ideally months or longer).  This means that the agents need to piece out their conversation topics over time, as well as discuss topics only if their “relationship” is deep enough.

I’ve tested and run with the Harry personality in ChatScript and it seems that the system wants to volunteer any and all of its gambits as soon as possible, then it quickly doesn’t know what to say anymore.

Is there a way in the current ChatScript to use some variables that keep some topics from being offered right away?

I’m imagining an agent that is “shy” at first, but after a while (several interactions over a long period of time) he warms up and talks more.

Sure.  One way is this:

topic: ~mytopic ()

t: (%input<100) keep() end(topic)  # prevents gambits from dishing until after 100 volleys

t: this is first real gambit.

You can similarly track how many “conversations” they have by incrementing a variable on each login—
$convocount += 1
and using that

t: ($convocount<5) keep() end(topic)  # blocks gambits until the 5th conversation.

That’s great.  I think I will use that.

Is there a way to set custom user variables outside of the conversation flow?

Currently, my architecture uses OpenSim for the virtual world.  Messages to the agents are routed through a Java service (using HTTP) which then sends the message to the ChatScript service (using a socket connection).  The response from CS is then sent back to OpenSim by the Java service.  The Java service itself maintains the complicated relationship variables.

Can the Java service set a variable on CS using the socket connection?

You can use “out of band” messages into CS. You attach stuff in brackets and decode it in CS.
Eg

input:  [ $timout=50 $setting=weak ] 

Whether you do this on normal user input (eg to pass in emotion detected via cameras or whatever) or whether you do it only on the null login startup message or whatever is up to you.
The format and interpretation is up to you.  Maybe you do
[ timeout 50 setting weak ]
and do something like:
u: (\[ * timeout _~number )  $timeout = _0
u: (\[ * setting _*1 ) $setting = ‘_0

Thanks Bruce.  This really helps.

I’ll work with this and see if this gives me what I need.

Pete, I’m working on the same sort of problem applied to gaming (think text based mmorpg) and my current thinking is that a lot of elements in relationships ( what you are really talking about is evolving shared context, ie a relationship ) are best handled/stored/computed outside the actual dialog system with clues to the dialog system being passed in as Bruce mentions.  I’m building in support for different chat engines and ideas like group conversations, etc so I need an intermediary anyway, but trying to model relationships using CS natively seemed to me like the wrong tool for the job.

On a slight tangent but still apropos - Chatscript has a total order HTN planner engine built in…

PS: I’ve switched from open sim to Unity3D - I found its graphics, language and networking support too limiting for my purpose.  Now you have me curious to take a second look for rapid POC of the relationship stuff…. Is it evolving fast enough to compete graphically?  Does it support c# more solidly now? (http://www.chatbots.org/ai_zone/viewthread/1701/)