123 lines
3.8 KiB
Text
123 lines
3.8 KiB
Text
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.
|
|
|
|
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.
|
|
|
|
The server lets you customize more tables than the ones in builtindir.
|
|
This is not recommended at this time. You can use the xdump command
|
|
to dump the default table to a file. The resulting table is in
|
|
machine-readable form, and may not be portable between different
|
|
server versions.
|
|
|
|
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");
|
|
}
|