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 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. 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"); }