Relations state is relatively bulky: it's a big chunk of struct
natstr, and adds 200 bytes per country to xdump nat.
Relations change rarely. Rewriting it to disk on every nation update
and retransmitting it in every xdump nat is wasteful.
To avoid this waste, move relations state to its own struct relatstr.
This is of course an xdump compatibility break. We're not maintaining
xdump compatibility in this release.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
New struct relatstr is basically empty so far. The next commit will
move relations state from struct natstr to struct relatstr.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Reject state is relatively bulky: it's a big chunk of struct natstr,
and adds almost 200 bytes per country to xdump nat.
Reject state changes rarely. Rewriting it to disk on every nation
update and retransmitting it in every xdump nat is wasteful.
To avoid this waste, move reject state to its own struct rejectstr.
This is of course an xdump compatibility break. We're not maintaining
xdump compatibility in this release.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
New struct rejectstr is basically empty so far. The next commit will
move reject state from struct natstr to struct rejectstr.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Contact state is relatively bulky: it's a big chunk of struct natstr,
and adds almost 200 bytes per country to xdump nat for deities.
Contact changes rarely. Since we avoid unnecessary updates, it
doesn't change at all unless option HIDDEN is enabled. Rewriting it
to disk on every nation update and retransmitting it in every deity
xdump nat is wasteful.
To avoid this waste, move contact state to its own struct contactstr.
This is of course an xdump compatibility break. We're not maintaining
xdump compatibility in this release.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
New struct contactstr is basically empty so far. The next commit will
move contact state from struct natstr to struct contactstr.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
A country must always be in contact of itself when option HIDDEN is
enabled. The code ensures this by establishing contact whenever a
player logs in, in init_nats(). This is not the proper place. Game
state should be initialized in empfile's oninit() callback, in this
case nat_oninit(). Do that, and drop the putcontact() from
init_nats().
Note that option LOSE_CONTACT only affects contact to other countries:
agecontact() doesn't age the country's contact to itself.
Use the opportunity to initialize contact so that getcontact() works
even when HIDDEN is disabled. Just cleanup, it isn't actually called
then.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
makelost() overwrites an existing entry for the same thing, else
creates a new one. It calls findlost() to find existing entries.
findlost() means to look up by coordinates if it's looking for a
sector entry, and by ID if it's looking for a ship, plane, land unit
or nuke entry. It actually does both for sectors. Since callers pass
zero ID for sectors, sector entries always match, so at most one gets
created, and additional ones overwrite it.
Broken since the lost table was introduced in 4.0.7. Fix the flawed
comparison in findlost().
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
People in sectors get plagued, then taxed or paid, then fed. People
on ships and land units get paid, then fed, then plagued. Sectors
were messed up when Empire 3 made the update code work for budget.
Change sectors back to how they worked before Empire 3: move do_feed()
from produce_sect() to prepare_sects(), and delay do_plague() until
after do_feed(). People in sectors now get taxed, paid and fed even
when they die of the plague, just like they do on ships and land
units.
Because do_plague() now runs after populace(), the latter's handling
of people dying off doesn't cover plague anymore. Delay it to the
very end of prepare_sects().
Additionally, move feeding and plaguing from upd_ship(), upd_land() to
prep_ship(), prep_land(), for consistency with sectors.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The update visits sectors in increasing order of country number.
Within a country, it visits in increasing order of sector number,
which is effectively top to bottom, left to right, starting with
absolute 0,0.
The order doesn't actually matter. Before Chainsaw's option BUDGET,
the update simply visited the sectors in sector number order. Go back
to that order, because it's faster. For the update, it's a few
percent in my testing. For budget, it's more than a third.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Ship, plane and land unit repair uses new work, except in sectors
owned by countries with a higher country number.
This inconsistency is an artifact of how the update is sequenced: we
work on countries one after the other. A country's ships, planes and
land units get repaired before higher-numbered countries' sectors
produce. Any ship, plane and land unit repairs in such sectors use
old work instead of new work.
Repair work use changed several times during Empire's history.
In BSD Empire, repairs use old work, because it updates ships and
planes before sectors.
Chainsaw added budget priorities and the budget command as option
BUDGET. Budget priorities let players choose separately for ships,
planes and land units whether to use old or new work for repairs.
The option also changed the update to work on countries one after the
other, presumably to permit a more efficient implementation of the
budget command.
Chainsaw also introduced repairs in foreign sectors under option
ALLYHARBORWORK.
With BUDGET disabled, all repairs still use old work, whether at home
or abroad. With BUDGET enabled, work use of repairs at home depends
on budget priorities, but work use abroad depend on country numbers.
Both options became standard in Empire 2.
Since v4.3.6, repairs at home always use new work (commit 967299a and
commit 520446e).
To make repairs abroad always use new work as well, we need to update
all sectors before any ship repair. This is straightforward: split
the loop over countries between sectors and unit building. For
symmetry, also split it between unit maintenance and sectors.
The budget command is differently broken, and will be fixed next.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
People in sectors first eat, then build the sector, then produce.
People in ships produce, eat, then build.
The starvation command can be off for fishing vessels, because it
doesn't consider the food they produce.
Change ships to match sectors. "Fixes" starvation. Fishing boats and
oil derricks being repaired at sea become a bit more productive.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Sector production computes a number of intermediate values, and rounds
many of them. We've tinkered with the rounding a few times. It
currently works as follows.
There are two production efficiencies, both shown by the production
command: sector p.e. (column eff) governs how efficiently work is
converted to units of production, and p.e. (column p.e.) governs how
much product each unit of production yields.
Production is limited by available work, materials and resource
contents. These limits are all rounded down.
Example: if a unit takes 16 work (tech or guns), then 600 work at 100%
sector p.e. can make at most 37 units, rounded down from 600 * 100% /
16 = 37.5. 76 work at 76% sector p.e. can make 3, rounded down from
76 * 76% / 16 = 3.61.
Output is units times p.e. Level output isn't rounded. Item output
is rounded down.
Example: a tech center making 37 units at p.e. 0.6 (edu=20) yields 37
* 0.6 = 22.2 tech (before tech log). 3 units yield 1.8 tech.
Example: a defense plant making 37 units at p.e. 0.6 (tech 35) yields
22 guns (rounded down from 22.2). 3 units yield 1.8g, randomly
rounded.
If item output needs to be adjusted downward (production backlog), the
number of units made is likewise adjusted. It is rounded randomly.
Example: a 100% refinery with 156 work can make 156 units. Its
p.e. at tech 30 is 5.0, so this yields 780p. But if it already has
9500p, it can make only 499 more. That's 99.8 units, rounded randomly
to either 99 or 100.
Materials and money consumed are a multiple of units made. No
rounding there.
Resource depletion depends on units made and is rounded randomly.
Work consumed is units made times work per unit divided by sector
production efficiency. Rounded randomly. Any work left can normally
be used at the next update (it "rolls over").
Example: the tech center making 37 units consumes 37 * 16 / 100% = 592
work, with 8 work left. It also consumes 37d 185o 370l $11100.
Example: the tech center making 3 units consumes 3 * 16 / 76% = 63.2
work, randomly rounded to 63 or 64, with 13 or 12 work left. It also
consumes 3d 15o 30l $900.
Example: the defense plant making 3 units consumes work the same. It
additionally consumes 1o 15l 30h $30 when it makes one gun, and twice
as much when it makes two.
Rounding intermediate values like "units of production" is awkward.
It's better to round only final results. These are item output,
materials consumed, resource depletion and work consumed. Round item
output down, and the rest randomly. Don't round level output (it's a
floating-point value) and money consumed (also floating-point, since
the previous commit).
For item production, this shifts the random variations from number of
products made to materials and work consumed.
Example: the first defense plant again makes 22 guns (now rounded down
from 22.5). The second one now always makes two guns (rounded down
from 3.61 * 0.6 = 2.166) instead of 1.8 randomly rounded.
This is nice, because budget and production can now predict the number
of items made exactly. Before, budget fluctuated randomly just like
the update, and production rounded down.
Note that budget used to be even worse: until commit 6f7c93c
(v4.3.31), we rounded units of production randomly rather than down.
The 100% tech center randomly made 37 or 38 units, which is much more
relevant than random rounding of item output.
Furthermore, work is now fully used both for item and level
production, to the limit permitted by materials and resource contents.
Example: the first tech center now makes 37.5 units, yielding 37.5 *
0.6 = 22.5 tech. It consumes 37.5d 187.5o 375l $11250 and all 600
work (fractions randomly rounded).
Example: the second tech center now makes 3.61 units yielding 1.805
tech, consuming 3.61d 18.05o 36.1l $1083 and all 76 work.
The production command duplicates much of the update's sector
production code, so it needs a matching update. The next commit will
reduce the duplication.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The update tallies income and expenses in full dollars. Each debit or
credit is rounded before it is added to the tally. Different things
are rounded differently. Examples:
* Each sector's military pay is rounded down. In the stock game, 1m
is paid $4.999998, so n mil cost n*$5 -$1, for all practical n. 10m
in one sector cost $49, but spread over ten sectors they cost only
$40.
* Total pay for military in ships and land units is rounded down.
* Each plane's military pay is rounded down (used to be rounded up
except for broke countries until recent commit 2eb08f4). In the
stock game, flight pay is 5 * $4.999998 = $24.99999. For a plane
with n mil, that's n * $25 - $1. Filed under plane maintenance, not
military payroll.
* Each sector's civilian tax is rounded. In the stock game, 1c pays
$0.499998. 10c in one sector pay $5, but spread over ten sectors
they pay nothing.
* An occupied sector's civilian tax is first rounded, then divided by
four and rounded down *boggle*.
* Each sector's uw tax is rounded. In the stock game, 1u pays
$0.106662. 1-4u in one sector pay nothing. 5-14u pay $1.
This is madness. Has always been that way.
Drop the rounding and track money in type double throughout the
update. Round only the final amount, randomly. This is similar to
how commands accumulate a money delta in player->dolcost.
Likewise, tally the subtotals for budget in type double. Display them
rounded to full dollars.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Extend struct budget member bm[] to cover ships, planes and land
units, too.
Plane maintenance changes because pilot pay is now consistently
rounded down. Before it was rounded down for broke countries, else
up. The stock game's pilots earn a little less than $25, and solvent
countries save $1 per plane. The rounding doesn't make much sense
either way. To be be addressed in a later commit.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Traditionally, unused unused available work is discarded at the
update. Since commit d7a054c (v4.2.13), deities can configure (some)
unused work to "roll over", i.e. available work = some unused work +
this update's work.
Not discarding unused work reduces micromanagement incentives.
However, it also leads to unobvious behavior.
For instance, here's the obvious way to build a radar station: move in
enough people to make 200 work. Half of it is available for sector
building, and increases efficiency to 100%. Here's a not-so-obvious
way: move in enough people to make 134 work. 67 will be used to
increase efficiency to 67%. Now move your workers elsewhere. The
unused available work is enough to finish the job at the next update.
Similarly, neighbors could be surprised by sectors building bridges
despite having no visible workers.
Commit 7f4e59f (v4.2.15) let deities limit the amount rolled over:
unused work above rollover_avail_max is discarded. This became the
default with a value of 50 in commit 81a3e4c4, v4.3.31.
Limit it further so that "roll over" can increase the update's work by
no more than half, plus one. The extra point is there so that even a
tiny work force has a chance to eventually eke out the second point of
work needed to increase efficiency.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Rounding work down can lead to a bit of work micromanagement. For
instance, four military on a lonely island accomplish nothing in 60
ETU updates, but five will make one point of work per update. They
can build a 2% harbor in four updates, as long as rollover_avail_max
is at least 3. Six to eight will be no faster.
The people's work used to be rounded randomly until Empire 3's big
effort to make the update code work for budget switched to rounding it
down, perhaps accidentally.
Switch back to rounding randomly, so that players don't have to get it
exactly right. Four military now get to 2% in five updates on
average, five in four, six or seven in three, and so forth.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
buildeff() rounds work and money up. Until recently, fractions could
only occur on tear-down, but with customized costs they can now also
occur on build-up.
The previous commit changed unit building to round money and work
randomly. Before, money was rounded down, and work was rounded up.
Round them randomly for sectors as well, for consistency.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
shiprepair() limits the efficiency gain to how much the workers can
build, rounding randomly. It charges work, money and materials for
the efficiency actually gained, rounding work up, money down, and
materials randomly. Same for planerepair() and landrepair(). Has
always been that way.
If you get lucky with the random rounding, you may get a bit of extra
work done for free.
The budget command runs the update code, and can be off by one due to
different random rounding.
Sector production used to have the same issue, only more serious,
because a single unit of tech production matters much more for the
budget than a single point of unit efficiency gain. I fixed it in
commit 6f7c93c, v4.3.31.
Fix it for unit building the same way: limit efficiency gain to the
amount the workers can produce (no rounding). Work becomes a hard
limit, not subject to random fluctuations. Randomly round work and
money charged for actual gain, like we do for materials. On average,
this charges exactly the work and money that's used.
This lets budget predict how much gets built a bit more accurately.
It's still not exact, as the amount of work available for building
remains slightly random, and the build cost is randomly rounded.
The old rounding of work for ships carries the comment "I didn't use
roundavg here, because I want to penalize the player with a large
number of ships." Likewise for planes. Rounding work up rather than
randomly increases the work cost by 0.5 per ship, plane or land unit
on average. I could keep the penalty by adding 0.5 before random
rounding. Not worth it, since the effect is actually pretty trivial.
Let's examine a fairly extreme case: an airfield with 600 available
work repairing a huge number of lightly damaged planes, say f2 with
81% average efficiency. The old code lets the airfield repair roughly
600 / 6.5 = ~92 planes, the new code 600 / 6 = 100.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
We maintain a few sector invariants in sct_prewrite(). Since the
update bypasses sct_prewrite(), it needs to maintain them itself. The
two should be consistent.
The update reverts deserted sectors to deity in three places:
do_plague(), populace() and produce_sect(). None of them is
consistent with sct_prewrite().
populace() can revert unowned sectors to deity. This creates bogus
entries in the "lost" file. Harmless; messed up when the lost items
were added in 4.0.7. Visible in tests/smoke/final.xdump.
populace() fails to revert when there are only uw left. If PLAGUE is
enabled, do_plague() already reverted. Else, produce_sect() will.
This is the only case where they add value to populace(). Can be
traced back all the way to BSD Empire 1.1.
All three neglect to clear mobility. Harmless.
Fix populace()'s condition for reverting to deity, and make it clear
mobility. Drop the reverting from do_plague() and produce_sect().
populace() also resets state that applies to civilians when there are
none: work percentage, loyalty and old owner. However, it resets on
different conditions than sct_prewrite(). Messed up in Chainsaw;
before, populace() didn't reset at all.
For sectors without military, populace() fails to reset. This can
happen when the update wipes out civilians and military, say by plague
or fallout. The now bogus work percentage, loyalty and old owner
persist until sct_prewrite() runs on the next non-update sector
update. Except old owner is reset correctly by populace() when the
sector reverts to deity. It doesn't when the owner has a land unit
there.
Most of the time, this doesn't matter, as moving civilians into a
sector without civilians overwrites the sector's work percentage,
loyalty and old owner. However, airlifting and unloading civilians
fail when the old owner differs from the owner. Else they adopt the
sector's loyalty and work percentage (bug#49 and bug#255).
Fix populace() to reset any sector without civilians, like
sct_prewrite().
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
We maintain a few sector invariants in sct_prewrite(). Since the
update bypasses sct_prewrite(), it needs to maintain them itself. The
two should be consistent.
sct_prewrite() resets work percentage of owned sectors to 100% when
there are no civilians. The update's populace() resets it for unowned
sectors as well, if they have military.
Change sct_prewrite() to reset sct_work = 100 regardless of owner.
Also change sct_oninit() to initialize sct_work = 100, so it doesn't
change on first write. Update tests/smoke/fairland.xdump for the same
reason.
The massive test output differences are all due to sct_work.
Inconsistencies with the update remain. They will be fixed next.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
In Empire, even babies work.
neweff and production compute the projected population's work,
discarding fractions.
The update first computes the adults' work (discarding fractions),
then newborns' work (discarding fractions), then adds them together.
Double rounding. Moreover, it uses the old work percentage for the
adults' work, and the new one for the newborns' work. Broken in
Empire 3.
Fix by recomputing work after grow_people(). This is how things
worked before the regression. Also restores a bug: growfood()'s work
use is ignored. Harmless, because fcrate and fgrate are too low for
growfood() to produce anything, and nobody customizes them. Mark
FIXME anyway.
Update test output changes as expected: available work differs in
sectors where double rounding discards work, an in sectors with
changing work percentage.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Tests need repeatable pseudo-random numbers to yield repeatable
results. Commit 73f1ac8 (v4.3.33) reseeds the PRNG with the count of
commands right before executing a command when running_test_suite is
on. This doesn't help the update: whenever update code exercised by a
test is changed to consume fewer or more PRNs, all subsequent users
get different numbers regardless. The ensuing test result changes are
extremely tedious to review.
To address this problem, reseed the PRNG in the update's two most
important loops with the iteration count when running_test_suite.
This way, the effect of perturbing the PRN sequence lasts only until
the next iteration.
There are many more loops, but reseeding in all of them seems
impractical.
Perturbs test results across the board. Hopefully, that'll happen
less frequently now.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
SAIL has issues:
* Sail orders are executed at the update. Crafty players can use them
to get around the update window.
* The route is fixed at command time. You can't let the update find
the best route, like it does for distribution.
* The info pages documenting it amount to almost 100 non-blank lines
formatted. They claim you can follow friendly ships. This is
wrong. They also show incorrect follow syntax. Unlikely to be the
only errors.
* Few players use it. Makes it a nice hidey-hole for bugs. Here are
two nice ones:
- If follow's second argument is negative, the code attempts to
follow an uninitialized ship. Could well be a remote hole.
- If ship #1 follows #2 follows #3 follows #2, the update goes into
an infinite loop.
* It's more than 500 lines of rather crufty code nobody wants to
touch. Thanks to a big effort in Empire 2, it shares some code with
the navigation command. It still duplicates other navigation code.
The sharing complicates fixing the bugs demonstrated by
navi-march-test.
Reviewing, fixing and testing this mess isn't worth the opportunity
cost. Remove it instead. Drop commands follow, mquota, sail and
unsail. Drop ship selectors mquota, path, follow.
struct shpstr shrinks some more, on my system from 160 to 120 bytes.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The autonavigation feature has issues:
* Autonavigation orders are executed at the update. Crafty players
can use them to get around the update window.
* Usability is poor:
- The order command is overly complex, not least because it can do
five different things: clear, suspend, resume, declare route, set
cargo levels.
- Unlike every other command involving movement, order does not let
you specify routes, only destination sectors.
- Setting cargo levels can silently swap start and end point of a
circular route, because "this keeps the load_it() procedure
happy". Maybe it does, but it surely keeps players confused.
- Setting "start" cargo levels actually sets the "end" levels, and
vice versa. Has always been broken that way.
- Predicting what exactly autonavigation will do at the update isn't
easy.
* The info pages documenting it amount to almost 400 non-blank lines
formatted. They claim only merchant ships can be given orders.
This is wrong. Unlikely to be the only error.
* Few players use it, and its workings at the update a fairly opaque.
Makes it a nice hidey-hole for bugs. Here are two:
- Unlike the scuttle command, autonavigation happily scuttles trade
ships while they're on the trading block.
- Unlike the load command, autonavigation can load in friendly and
allied sectors.
* It's more than 700 lines of rather crufty code nobody wants to
touch. Thanks to a big effort in Empire 2, it shares code with the
navigation command. It still duplicates load code. The sharing
complicates fixing the bugs demonstrated by navi-march-test.
Reviewing, fixing and testing this mess isn't worth the opportunity
cost. Remove it instead. Drop commands order, qorder and sorder.
Drop ship selectors xstart, xend, ystart, yend, cargostart, cargoend,
amtstart, amtend, autonav.
xdump ship sheds almost half its columns. struct shpstr shrinks, on
my system from 200 to 160 bytes.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Cuts size of export files in test suite by a factor of four. Not a
big deal for disk usage, as export files compress very well, and disk
space is cheap anyway. Export files are simply easier to work with
when they aren't full of redundant crap.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
scrap has always returned the scrapped planes' full crew, regardless
of efficiency. build, however, charged only 10%. If you built ten
planes with one crew each, you used up one military. Or none, if you
abused random rounding. If you scrapped them again, you got ten back.
Pretty pricey way to manufacture military, but wrong all the same.
4.2.3 plugged this hole by making build never round military to zero.
Ugly special case, and not documented. Also doesn't prevent abuse of
random rounding for planes requiring more than 10 crew, but such
planes don't exist in the stock game.
Redo this fix:
1. Make scrap return crew proportional to efficiency, randomly
rounded. Note that scrap returns only two thirds of the other
materials, rounded down. Recycling materials isn't perfect, but
recycling aircrew is.
2. Drop the special case from build: treat military just like other
materials.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Construction materials required for building a ship, plane or land
unit are rounded randomly. Crafty players exploit this to save
materials: they put just enough materials there so that build succeeds
when it rounds down. Then they simply keep trying until it succeeds.
Planes and land units are built at 10%, so rounding happens when
materials for 100% aren't multiples of ten. If they're below ten, you
can even build without materials. In the stock game, this is the case
for linf, and many plane types.
Ships are built at 20%, so multiples of five aren't rounded. Ship
building never rounds in the stock game.
Prevent the abuse of random rounding by requiring the required
fractional amount rounded up to be present. Don't change the actual
charging of materials; that's still randomly rounded.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
TREATIES has issues:
* Treaties can cover attack, assault, paradrop, board, lboard, fire,
build (s|p|l|n) and enlist, but not bomb, launch, torpedo and
enlistment centers.
* Usability is very poor. While a treaty is in effect, every player
action that violates a treaty condition triggers a prompt like this:
This action is in contravention of treaty #0 (with Curmudgeon)
Do you wish to go ahead anyway? [yn]
If you decline, the action is not executed. If you accept, it is.
In both cases, your decision is reported in the news.
You cannot get rid of these prompts until the treaty expires.
* Virtually nobody uses them.
* Virtually unused code is buggy code. There is at least one race
condition: multifire() reads the firing sector, ship or land unit
before the treaty prompt, and writes it back after, triggering a
generation oops. Any updates made by other threads while trechk()
waits for input are wiped out, triggering a seqno mismatch oops.
* The treaty prompts could confuse smart clients that aren't prepared
for them. WinACE isn't, but is reported to work anyway at least
common usage. Ron Koenderink (the WinACE maintainer) suspects there
could be a few situations where it will fail.
This feature is not earning its keep. Remove it. Drop command
treaty, consider treaty, offer treaty, xdump treaty, reject treaties.
Output of accept changed, obviously.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Tests need repeatable pseudorandom numbers to yield repeatable
results. We seed the pseudorandom number generator with a fixed value
(emp_server -R) to make it produce the same sequence of numbers every
time. But whenever code exercised by a test is changed to consume
fewer or more of them, all subsequent users get different numbers
regardless. The ensuing test result changes are extremely tedious to
review.
To address this problem, reseed the PRNG with the count of commands
right before executing a command when running_test_suite is on. This
way, the effect of perturbing the PRN sequence lasts only until the
next command.
Note that the next command could be another player's. Doesn't matter.
Adding or removing commands now upsets the PRN sequence even for
commands that don't consume PRNs. The next commit will take care of
that.
Perturbs test results across the board. Hopefully, that'll happen
much less frequently now.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The other test output files have fixed names, and having just one with
a name that varies with the test name complicates things with no gain.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
