A single ChatScript server can dish hundreds of volleys per second (with Windows doing about twice as many as Linux). Since users can’t type that fast, this means it dishes hundreds of users per second. And it makes no difference whether you have a single bot or multiple bots.

Multiple bots can each have their own topics and can share topics and share responders. 
topic: ~music [song] # this topic can be used by all bots

topic: ~food bot=ben [sandwich] # only ben can use this topic
topic: ~food bot=barry [sandwich] # only barry can use this one

Within a topic, to write a responder that can say different things based on which bot you have, one could do this:
u: (sandwich)  if ($bot == ben) {$choice1 = true} else {$choice2 = true}
[$choice1 Ben says this.] [$choice2 Barry says this.]

But there are various flaws with this design. First, assuming that $choice1 and $choice2 are intended to be locally used, one should have said $$choice1 and $$choice2 so the values disappear at the end of the volley. Otherwise some other responder on a different volley may find values true that shouldn’t be, e.g.,

u: (sandwich)  if ($bot == barry) {$choice1 = true} else {$choice2 = true}
[$choice1 Ben says this.] [$choice2 Barry says this.]

Second, the [] [] construct is intended to randomize things, but no randomization happens here. This would be better written (faster and clearer) simply not using []  such as:
u: (sandwich)
if ($bot == barry) {Barry says this.}
else {Ben says this.}

Another flaw: why set these variables locally. If they reflect which bot you have, you can set them once at bot initialization time:
outputmacro: ben()
$bot = ben
$ben = true

And once you have the choice variables as globals, then your responders are simply:
u: (sandwich) [$ben Ben says this.] [$barry Barry says this.]

This works equally well for a mood-based bot:
u: (sandwich) [$ben-angry Angry ben says] [$ben-happy Happy ben says]

But when you have a lot of bots that say long paragraphs, you can overload the size constraints on a responder.  There is another way that doesn’t.
u: (sandwich) ^refine()
a: ($bot=ben) This is ben.
a: ($bot=barry) This is barry.
Of course one could have used the $ben and $barry variables to avoid the equality test. And you can have bots with moods like this:
u:(sandwich) ^refine()
a: ($ben) ^refine()
  b: ($ben_mood=angry)
  b: ($ben_mood = happy)
a: ($barry) ^refine

Topics also have size limits, but they are easy to handle just by nesting a topic:

u: (sandwich) ^respond(~sandwich_topic)

I don’t know exactly how chatscript works, but can’t you work with multiple files? Say, you have 1 file with responses that all bots share, and each bot has its own additional file. When a bot is started, it loads all shared and personal files. This means that you don’t have to make nasty constructs to check which bot it is (imagine having 10 bots and adding an eleventh one, which would mean modifying all rules).

You don’t have to modify all rules or make nasty constructs. As an alternative, you can just mark a topic as suitable only for a specific bot or suitable for all. 

Structure “topic: ~food bot=ben [sandwich]” works on Win32, Linux64, but doesn’t work on Linux32. When I remove “bot=ben” - it works, restore - it fails. Any ideas?

v.1.99

On Win32 and Linux64 (properly working copies) in script1.txt we can see smth like this:
“TOPIC: ~introductions 0 17343397299735850946 93 ” harry ben georgia ” 01c t: ( =8%input<%userfirstline ) ^noerase ( ) ^gambit ( ~introductions)”
On linux32 content looks like:
“TOPIC: ~introductions 0 17343397299735850946 93 ”  ” 01c t: ( =8%input<%userfirstline ) ^noerase ( ) ^gambit ( ~introductions)”
Finally we’ve found solution (but it’s a hack ): we’ve replaced TOPIC folder content of Linux32 for the same content of Linux64.

I tried an amazon server 32 bit machine:

topic: ~food bot=harry [sandwich] 
t: junk

topic: ~foodx bot=ben [sandwich]
t: hi

and it build correctly labeled topic data just fine.

But you say you saw: harry ben georgia…. Which makes no sense from input of bot=ben.
for ALL bots one would see ” all ” unless you enumerated some bots or had stale data somehow from an old release maybe

It was just an example. Of course, if I have in topic “bot=ben”, script looks like “TOPIC: ~introductions 0 17343397299735850946 93 ” ben ” 01c t: ( =8%input<%userfirstline ) ^noerase ( ) ^gambit ( ~introductions)”.

so, can you give me the REAL topic header? I don’t need the content of the topic, just the header.
OR- should your example have used multiple bots names instead of the single one you showed… assuming that, can you try the experiment of seeing of topic: foodx bot=ben,mary,john [sandwich]  fails?

I’ve sent you an email with samples.

Bruce Wilcox - Jan 7, 2012:

so, can you give me the REAL topic header? I don’t need the content of the topic, just the header.
OR- should your example have used multiple bots names instead of the single one you showed… assuming that, can you try the experiment of seeing of topic: foodx bot=ben,mary,john [sandwich]  fails?

what about 2202 line in scriptCompile.cpp?

Do you sure you mean “-3” nor “+3” in strlen() args?

the corrected answer in source is:
topicName->w.topicRestriction = AllocateString(botlist+3,strlen(botlist) - 3);

we are skipping the 1st 3 characters in copy, and the length is the total length minus those three.
The actual code did strlen using a junk address.

I think “strlen(botlist)-3” is the same “strlen(botlist+3)” in this case, but no matter…

it is, and I must confess the +3 form is fractionally faster.