This is a short note on the Empire run-time configuration stuff.  Some
of this is for deities to enable them to configure things, some of it
is for coders to see how this stuff works.

Julian Onions <j.onions@nexor.co.uk>  15/7/95

--

Deity Information
-----------------

To find out the compiled-in configuration, the simplest method is to
run pconfig.  It can be run either with no arguments, in which case it
will print the current compiled-in configuration in econfig format.
Otherwise, with a file name argument, it will first read in this file,
and override any compiled in variables, and then print the merged
configuration.

So the first method shows you what's compiled in, the second how a
config file would modify this.

Blank lines are ignored, as are lines starting with a # character.

A line of the form KEY VALUE configures an econfig key to a value.  A
value is either a string (quote using " to get spaces in it), an
integer or a floating-point number, depending on the key.

For instance,
    data "/empire/data"
configures the data directory to that place, and
    port "7777"
configures the empire port to 7777,
    btu_build_rate 0.0004
configures the BTU build rate, and so on.

The programs look for the config file in a compiled-in location, which
is shown by emp_server -h.  Use -e to make the programs use another
config file instead.  Thus, to start two games on the same host, you
might have

Game1:
files -e econfig1
fairland -e econfig1
emp_server -e econfig1

Game2:
files -e econfig2
fairland -e econfig2
emp_server -e econfig2

econfig1 might have the lines

data "/empire/data1"
info "/empire/info.nr"
port "7777"

and econfig2 might have the lines

data "/empire/data2"
info "/empire/info.nr"
port "7778"

You only need the lines in that file that you require to override the
compiled-in definitions, however having all the definitions may help
you to understand what is on and off.  You could do this with

pconfig econfig1 > e1 && mv e1 econfig1
pconfig econfig2 > e2 && mv e2 econfig2

which will fill in all the missing keys and values with their defaults.

You define your update schedule in the schedule file, in the same
directory as your econfig.  See doc/schedule for details.

Additional customization is possible through key custom_tables, which
is a list of files containing tables in xdump format (see doc/xdump
for technical information on xdump).  To customize a table, copy the
default table from the directory given by econfig key builtindir to a
file next to your econfig, then name the file in custom_tables.  Do
*not* edit the default table in-place!  That bypasses important
consistency checks.

Be careful not to put `holes' into tables, e.g. by commenting out
entries.  That doesn't work yet.

A word of caution: Just because you can customize something doesn't
mean you should!  The server makes an effort to catch mistakes that
could crash the game.  It has no chance to catch mistakes that
unbalance it.


Coder information
-----------------

The simplest way to describe this is perhaps to step through how a new
key would be added.  Let's do this for a new option "DUMB".

1. Define the variable for the key.  Options go into
src/lib/global/options.c, like this:

int opt_DUMB = 1;

The initializer provides the compiled-in value.

Other keys go into src/lib/global/constants.c.

2. Declare the econfig key in include/econfig-spec.h:

EMPCF_OPT("DUMP", opt_DUMP, "Enable additional dumbness")

For a non-option key, you'd use EMPCFBOTH() there.

The declaration is visible both in include/optlist.h as an external
variable, and in struct keymatch configkeys[], which is used by the
econfig parser.

3. Use the variable in your code.  This normally looks like

	  if (opt_DUMB) {
	      pr("You're being dumb\n");
	  } else {
	      pr("You're being really dumb\n");
	  }
