noboot 
port=20

language=english

language=english,spanish,german,japanese

language: UNIVERSAL
RAWDATA/ONTOLOGY/       # underlying vocabulary organization
language: ENGLISH
RAWDATA/ONTOLOGY/ENGLISH//
RAWDATA/WORLDDATA/
language: GERMAN
RAWDATA/ONTOLOGY/GERMAN//
language: SPANISH
RAWDATA/ONTOLOGY/SPANISH//

	concept: ~food ("baked potato") with input "baked potatoes"
				legacy=1 : (_~food) =>  '_0 - baked_potatoes  _0 - bake_potato
				legacy=0 : (_~food) => '_0 - baked_potatoes  _0 - baked_potato

if (_0 == unknown-word){_0 = '_0'} 
```'

Trustpos is normally off by default because CS is only about 94% accurate in its
built-in pos-tagging. So it prefers to wrongly match by allowing all pos values Of
a word rather than miss a match. Ergo concept: ~all(feel~n) will match any use of "feel" rather than
just noun meaning. But combining CS with Treetagger for english (if you license it) is better at
pos-tagging than either alone, making it competitive with the best taggers in the world.
    

Here few command line parameters usage examples of usual edit/compile developement phase, running ChatScript from a Linux terminal console (standalone mode):

Rebuild _level0_ (compiling system ChatScript files, listed usually in file `files0.txt`):

Rebuild _level1_, compiling bot _Mybot_ (files listed in file `filesMybot.txt`), showing build report on screen (stdout):

Rebuild and run: If building phase is without building errors, you can run the just built _Mybot_ in local mode (interactive console) with user name _Amy_:

Build bot _Mybot_ and run ChatScript with user _Amy_: 

## Bot variables (aka Server variables)

You can create predefined bot variables by simply naming permanent variables on the
command line, using V to replace $ (since Linux shell scripts don't like $). Eg.

Quoted strings will be stored without the quotes. Bot variables are always reset to their
original value at each volley, even if you overwrite them during a volley. This can be
used to provide server-host specific values into a script. Nor will they be saved in The
user's topic file across volleys.  This also applies to variables defined during any CS_BOOT


## No such bot-specific - nosuchbotrestart=true

If the system does not recognize the bot name requested, it can automatically restart a
server (on the presumption that something got damaged). If you don't expect no such bot
to happen, you can enable this restart using `nosuchbotrestart=true`. Default is false.


## Time options
| option           | description
|------------------|-----------------------------------------------------------------------------
| `Timer=15000`    | if a volley lasts more than 15 seconds, abort it and return a timeout message.
| `Timer=18000x10` |same as above, but more roughly, higher number after the x reduces how frequently it samples time, reducing the cost of sampling
| `Timelog=5000`    | if a volley lasts more than 5000 milliseconds, record it in LOGS/time.txt and for LINUX in /log/cstime.txt .

## `:TranslateConcept` Google API Key
| option           | description
|------------------|-----------------------------------------------------------------------------
| `apikey=xxxxxx`  | is how you provide a google translate api key to `:translateconcept`

# Security

Typically security parameters only are used in a server configuration.

| option           | description
|------------------|-----------------------------------------------------------------------------
| `sandbox`        | If the engine is not allowed to alter the server machine other than through the standard ChatScript directories, you can start it with the parameter `sandbox` which disables Export and System calls.
| `nodebug`        | Users may not issue debug commands (regardless of authorizations). Scripts can still do so.
|`authorize=""`| bunch of authorizations "". The contents of the string are just like the contents of the authorizations file for the server. Each entry separated from the other by a space. This list is checked first. If it fails to authorize AND there is a file, then the file will be checked also. Otherwise authorization is denied.
|`encrypt=xxxxx`<br>`decrypt=xxxxx` | These name URLs that accept JSON data to encrypt and decrypt user data. User data is of two forms, topic data and LTM data. LTM data is intended to be more personalized for a user, so if `encrypt` is set, LTM will be  encrypted. User topic data is often just execution state of the user and potentially big, so by default it is not encrypted. You can request encryption using `userencrypt` as a command line parameter to encrypt the topic file and `ltmdecrypt` to encrypt the ltm file.

The JSON data sent to the URL given by the parameters looks like this:

where ... is the text to encrypt or decrypt. Data from CS will be filled into the ... and are JSON compatible.


# Server Parameters

Either Mac/LINUX or Windows versions accept the following command line args:

| option                | description
|-----------------------|-----------------------------------------------------------------------------
| `port=xxx`            | This tells the system to be a server and to use the given numeric port. You must do this to tell Windows to run as a server. The standard port is 1024 but you can use any port.
| `local`               | The opposite of the port command, this says run the program as a stand-alone system, not as a server.
| `interface=127.0.0.1` | By default the value is `0.0.0.0` and the system directly uses a port that may be open to the internet. You can set the interface to a different value and it will set the local port of the TCP connection to what you designate. 127 is the classic TCP port.

# User Data

Scripts can direct the system to store individualized data for a user in the user's topic file
in USERS. It can store user variables (`$xxx`) or facts. Since variables hold only a single
piece of information a script already controls how many of those there are. But facts can
be arbitrarily created by a script and there is no natural limit. 
As these all take up room in the user's file, affecting how long it takes to process a volley 
(due to the time it takes to load and write back a topic file), 
you may want to limit how many facts each user can have written. 
This is unrelated to universal facts the system has at its permanent disposal as part of the base system.

`userfacts=n` limits a user file to saving only the n most recently created facts of a user (this does not include facts stored in fact sets). 
Overridden if the user has `$cs_userfactlimit` set to some value

### User Caching

Each user is tracked via their topic file in USERS. The system must load it and write it
back for each volley and in some cases will become I/O bound as a result (particularly if
the filesystem is not local). 

You can direct the system to keep a cache in memory of recent users, to reduce the I/O volume. 
It will still write out data periodically, but not every volley. 
Of course if you do this and the server crashes, 
writebacks may not have happened and some system rememberance of user interaction will be lost. 

Of course if the system crashes, user's may not think it unusually that the chatbot forgot some of what happened. 
By default, the system automatically writes to disk every volley, If you use a different value, 
a user file will never be more out of date than that.

This specifies how many users can be cached in memory and how big the cache block in
kb should be for a user. The default block size is `50` (50,000 bytes). 
User files typically are under 20,000 bytes.

If a file is too big for the block, it will just have to write directly to and from the filesystem. 
The default cache count is 1, telling how many users to cache at once, 
but you can explicitly set how many users get cached with the number after the
"x". If the second number is 0, then no caching is done and users have no data saved.
They remember nothing from volley to volley.

Do not use caching with fork. The forks will be hiding user data from each other.

This specifies how many volleys should elapse before a cached user is saved to disk.
Default is 1. A value of 0 not only causes a user's data to be written out every volley, but
also causes the user record to be dropped from the cache, so it is read back in every time
it is needed (handy when running multi-core copies of chatscript off the same port). 

Note, if you change the default to a number higher than 1, you should always use `:quit` 
to end a server. Merely killing the process may result in loss of the most recent user activity.

## Logging or Not

In stand-alone mode the system logs what a user says with a bot in the USERS folder. It
can also do this in server mode. It can also log what the server itself does. But logging
slows down the system. Particularly if you have an intervening server running and it is
logging things, you may have no use whatsoever for ChatScript's logging.

Store a user-bot log in USERS directory. Stand-alone default if unspecified.
Alternatively you can do  userlog=1   to enable.

Don't store a user-bot log. Server default if unspecified.
Alternatively you can do  userlog=0   to disable.
Alternatively you can do userlogging=none.

Write a server log and a bugs log. 
Alternatively you can do  serverlog=1   to enable to file,  2 to use stdout, 4 to use stderr. You can combine like serverlog=5
Prefer the alternate form of request,  serverlogging=none for off and file, stdout, stderr.  - you may combine serverlogging=file,stdout
Last form scanned (read in order from cs_init.txt and then cs_initmore.txt) wins.

The server log will be put into the LOGS directory under serverlogxxx.txt where xxx is the port. 

The bugs log is in the same directory under bugs.txt (all ports).

The server log records all transactions by all users in order of arrival. Whereas the user log
records transactions by user/bot.

The server log can be written regardless of whether CS is running in
server mode or not.

In addition to permanently turning on server and/or user logging, you can provide a cheat code in your
input that, if it matches the serverlogauthcode, will enable server and user logging for that input. This code
is hidden from CS processing so it will not impact NL processing.

In calls to ^testpattern, this will log to return in a `trace` field. By
default, this code will just trace patterns. But if you concat `2` onto the
code it will do a full cs trace.

In calls to ^testouput, this will log to return in a trace field but will always
be a full trace.

If there is data you don't want reflected into either server or user log files, this is the parameter. Maybe you don't
want an authorization code recorded, or whatever. This presumes the data is part of some JSON object. You name one or more labels
and when those are found in data outbound to a log file, the label and its value will be omitted.

Have server terminate its output with 0x00 0xfe 0xff as a verification the client received
the entire message, since without sending to server, client cannot be positive the
connection wasn't broken somewhere and await more input forever.

This asserts that cs in DLL/sharedobject form is being used as a server (though its caller is doing all the server work).
This enables the required authorizations from CS before using debug commands.

Superceeded by `serverloggging=`.
Don't write a server log or a bugs log.
Alternatively you can do  serverlog=0   to disable.

Don't write a  bugs log. Same as Buglog=0 or Buglog=none

Write a LOGS/bugs.txt log if n = 1. Write nothing if n == 0. 
Alternate form of request, you can use buglogging=none for off and file, stdout, stderr.  - you may combine buglogging=file,stderr

Sets debug level of server logging. 0 will remove logging all the startup variables and their values.

If using LINUX EVSERVER, you can request extra copies of ChatScript (to run on each
core for example). n specifies how many additional copies of ChatScript to launch.

Allows `:retry` to work from a server - don't use this except for testing a single-person 
on a server as it slows down the server.

when present, forces all users to have tracing turned on. Traces go to the user logs.

Servers are subject to malicious inputs, often generated as repeated words over and over.
This detects repeated input and if the number of sequential repeats is non-zero and equal or
greater to this parameter, such inputs will be truncated to just the initial repeats. All
other input in this volley will be discarded.

:reset, when called from running script, is unable to fully reset the system.
Facts that have already been created are not destroyed and user variables that have been
defined are not erased, only ones in the bot definition are changed back to their default
settings.  The erasename parameter is used to perform a full reset prior to loading the
user topic file. The incoming input is scanned for the text given, and if found the
system bypasses loading the topic file and instead just initializes a fresh bot.
The actual erasename seen in input will be converted to all blanks, so it will not disturb
normal behavior, either in OOB input or user input.

The default value for this is: `csuser_erase` which you can change to anything else you want.

The cs_new_user parameter is used to perform a full reset prior to loading the
user topic file. The incoming input is scanned for the text given, and if found the
system bypasses loading the topic file and instead just initializes a fresh bot.
This differs from erasename in that the text is not erased. 

## No such bot-specific - nosuchbotrestart=true

If the system does not recognize the bot name requested, it can automatically restart a
server (on the presumption that something got damaged). If you don't expect no such bot
to happen, you can enable this restart using `nosuchbotrestart=true`. Default is false.


## Testing a server

There are various configurations for having an instance be a client to test a server.

This says be a client to test a remote server at IP xxxx and port yyyy. You will be able to
"login" to this client and then send and receive messages with a server.

This says be a client to test a local server on port yyyy. Similar to above.

This creates a localhost client that constantly sends messages to a server. Works its way
through `REGRESS/bigregress.txt` as its input (over 100K messages). Can assign different
numbers to create different loading clients (e.g., load=10 creates 10 clients).

Yet another client. But this one feeds the output of the server back as input for the next
round. There are also command line parameters for controlling memory usage which are not
specific to being a server.