Wolfpack Empire - mirror of https://git.pond.sub.org/empserver
http://wolfpackempire.com/
Markus Armbruster
6f7c93cdad
produce() limits production to how many units the workers can produce, rounding randomly. It charges work for the units actually produced, discarding fractions. If you get lucky with the random rounding, you may get a bit of extra work done for free. Else, you get to keep the unused work, and may even be undercharged a tiny bit of work. Has always been that way. The production command assumes the random rounding rounds up if and only if the probability to do so is at least 50%. Thus, it's frequently off by one for sectors producing at their worker limit. The budget command runs the update code, and is therefore also off by one, only differently. Rather annoying for tech and research centers, where a single unit matters. A tech center with full civilian population can produce 37.5 units in 60 etus. Given enough materials, it'll fluctuate between 37 and 38. Production consistently predicts 38, and budget randomly predicts either 37 or 38. Both are off by one half the time. Fix this as follows: limit production to the amount the workers can produce (no rounding). Work becomes a hard limit, not subject to random fluctuations. Randomly round the work charged for actual production. On average, this charges exactly the work that's used. More importantly, production and budget now predict how much gets produced more accurately. They're still not exact, as the amount of work available for production remains slightly random. This also "fixes" the smoke test on a i686 Debian 6 box for me. The root problem is that floating-point subexpressions may either be computed in double precision or extended precision. Different machines (or different compilers, or even different compiler flags) may use different precision, and get different results. Example: producing 108 units at one work per unit, sector p.e. 0.4 needs to charge 108 / 0.4 work. Computed in double precision, this gets rounded to 270.0, then truncated to 270. In 80 bit extended precision, it gets rounded to 269.999999999, then truncated to 269. With random rounding instead of truncation, the probability for a different result is vanishingly small. However, this commit introduces truncation in another place. It just happens not to mess up the smoke test there. I doubt this is the last time this kind of problem upsets the smoke test. |
||
|---|---|---|
| doc | ||
| include | ||
| info | ||
| m4 | ||
| man | ||
| scripts | ||
| src | ||
| tests | ||
| .gitignore | ||
| .travis.yml | ||
| bootstrap | ||
| compile | ||
| config.guess | ||
| config.sub | ||
| configure.ac | ||
| COPYING | ||
| CREDITS | ||
| depcomp | ||
| GNUmakefile.in | ||
| INSTALL | ||
| install-sh | ||
| Make.mk | ||
| README | ||
Welcome to Empire 4, code-named Wolfpack.
Empire is a multi-player, client/server Internet based war game.
Copyright (C) 1986-2013, Dave Pare, Jeff Bailey, Thomas Ruschak,
Ken Stevens, Steve McClure, Markus Armbruster
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License (in file
`COPYING'), or (at your option) any later version.
See file `CREDITS' for a list of contributors.
Directory `doc' has additional information. File `doc/README'
describes the files there and what they talk about.
To build the server and set up a game, follow the steps below.
(1) Unpacking the source tree
If you downloaded a tarball, unpack it.
If you cloned a git repository, run bootstrap. This requires
recent versions of Autoconf and Automake to be installed.
(2) Building a server
Prerequisites: IEEE Std 1003.1-2001 (POSIX.1-2001), GNU make, a
curses library, Perl, and either nroff or GNU troff (`groff').
See file `INSTALL' for detailed compilation and installation
instructions. Quick guide for the impatient: run configure; make;
make install. The last step is optional; everything runs fine
right from the build tree.
If make fails without doing anything, you're probably not using
GNU make. Some systems have it installed as `gmake'.
Solaris supports POSIX.1-2001, but you need to set up your
environment for that. Try passing
SHELL=/usr/xpg4/bin/sh PATH=/usr/xpg6/bin:/usr/xpg4/bin:$PATH
to make. See standards(5) for details.
(3) Creating a game
* Create a configuration for your game. make install installs one
in $prefix/etc/empire/econfig ($prefix is /usr/local unless you
chose something else with configure). You can use pconfig to
create another one.
* Edit your configuration file. See doc/econfig for more
information.
Unless you put your configuration file in the default location
(where make install installs it), you have to use -e with all
programs to make them use your configuration.
* Run files to set up your data directory.
* Run fairland to create a world. For a sample world, try
`fairland 10 30'. This creates file ./newcap_script, which will
be used below. You can edit it to change country names and
passwords.
Check out fairland's manual page for more information.
* Start the server. For development, you want to run it with -d
in a debugger, see doc/debugging. Do not use -d for a real
game!
* Log in as deity POGO with password peter. This guide assumes
you use the included client `empire', but other clients should
work as well.
For help, try `info'.
To change the deity password, use `change re <password>'.
* Create countries with `exec newcap_script'.
Your game is now up!
Naturally, there's more to running a real game than that, but that's
beyond the scope of this file.
Please report bugs to <wolfpack@wolfpackempire.com> or via SourceForge
http://sourceforge.net/projects/empserver (registration required).
For more information or help, try rec.games.empire on Usenet, or send
e-mail to <wolfpack@wolfpackempire.com> and we'll try to answer if we
can. Also check out our web site at "http://www.wolfpackempire.com".
Have fun!
Wolfpack!