111 lines
3.1 KiB
Text
111 lines
3.1 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
|
|
|
|
--
|
|
Also, the Empire config files are now self-documenting (to a point.)
|
|
Each option/variable now has a comment associated with it to hopefully
|
|
make life easier on deities wanting to change things.
|
|
|
|
-- Steve McClure, 10/21/1998
|
|
--
|
|
|
|
Deity Notes
|
|
-----------
|
|
|
|
To find out the compiled-in configuration, the simplest method is to
|
|
compile up util/pconfig and the run it. It can be run either with no
|
|
arguments, in which case it will print in config format the current
|
|
compiled-in configuration. Otherwise, with a file containing a
|
|
configuration, 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 a 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.
|
|
|
|
|
|
|
|
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");
|
|
}
|