empserver
5 years agoproduction: Use update code instead of duplicating it
Markus Armbruster [Thu, 7 Jul 2016 06:03:58 +0000 (08:03 +0200)]
production: Use update code instead of duplicating it

prod() duplicates the update's sector production code, except it
computes both output with present materials ("make" output) and output
not limited by lack of materials or production backlog ("max" output).
It also rounds materials consumed up instead of randomly.

Factor prod_output() out of produce() for reuse by prod().  prod()
runs it twice: once for "make" output and once for "max" output.

Test output changes are due to random rounding.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate production: Make sector production a bit more predictable
Markus Armbruster [Wed, 6 Jul 2016 19:35:38 +0000 (21:35 +0200)]
update production: Make sector production a bit more predictable

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>
5 years agoupdate: Don't double-round money, fixing mil pay and more
Markus Armbruster [Wed, 6 Jul 2016 17:36:33 +0000 (19:36 +0200)]
update: Don't double-round money, fixing mil pay and more

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>
5 years agobudget: Fix treasury tracking
Markus Armbruster [Sun, 19 Jun 2016 09:32:36 +0000 (11:32 +0200)]
budget: Fix treasury tracking

The update simply updates each nation's nat_money as it goes.  Works.
Except it doesn't update when it runs on behalf of budget.  But it
still checks nat_money to determine whether the nation is solvent.
These checks are all broken.  Leads to massive mispredictions when
you'd go broke or solvent during a real update.

Track money unconditionally in nat_budget[].money.  Delay update of
nat_money until prod_nat().  Replace separate money[] by new
nat_budget[].start_money.  Closes bug#235.

Remaining difference between budget and update in the update test:

* #1: budget mispredicts plane #100 gets built (to be fixed)

* #2: budget shows ship, plane and land unit maintenance when broke,
      but update damages them instead (correct)

* #2: sector -14,0 converts, quadrupling its taxes (correct)

* #4 & #5: bank with dust and bars taken over by che (correct)

* #4: plague deaths (correct)

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate: Push budget update into produce(), enlist()
Markus Armbruster [Sun, 19 Jun 2016 07:09:46 +0000 (09:09 +0200)]
update: Push budget update into produce(), enlist()

produce() and enlist store the cost through a parameter and return the
amount.  Their caller produce_sect() then updates nat_budget[]
accordingly.  Move the nat_budget[] update into the callees.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate: Get army, navy, air force delta from nat_budget[]
Markus Armbruster [Sat, 18 Jun 2016 21:03:04 +0000 (23:03 +0200)]
update: Get army, navy, air force delta from nat_budget[]

lnd_money[], sea_money[] and air_money[] have become redundant.
Eliminate them.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agobudget: Track bank interest in nat_budget[]
Markus Armbruster [Sat, 18 Jun 2016 20:33:25 +0000 (22:33 +0200)]
budget: Track bank interest in nat_budget[]

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agobudget: Track taxes in nat_budget[]
Markus Armbruster [Sat, 18 Jun 2016 20:26:05 +0000 (22:26 +0200)]
budget: Track taxes in nat_budget[]

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agobudget: Use a loop to show build and maintenance
Markus Armbruster [Sat, 18 Jun 2016 15:41:18 +0000 (17:41 +0200)]
budget: Use a loop to show build and maintenance

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agobudget: Track ship, plane, land unit expenses in nat_budget[]
Markus Armbruster [Sat, 18 Jun 2016 15:00:16 +0000 (17:00 +0200)]
budget: Track ship, plane, land unit expenses in nat_budget[]

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>
5 years agobudget: Track sector expenses in nat_budget[]
Markus Armbruster [Sat, 18 Jun 2016 13:33:05 +0000 (15:33 +0200)]
budget: Track sector expenses in nat_budget[]

The update summarizes sector production, building and maintenance for
budget in a two-dimensional array int p_sect[SCT_BUDG_MAX+1][2].  All
references into this array use literals as second subscript.  Bzzzt,
wrong data type.

Add two one-dimensional arrays to nat_budget[], one for production,
and one for building and maintenance.  p_sect[i] becomes
nat_budget[cnum].prod[i] for production, and .bm[j] for building and
maintenance.  p_sect[i][0] becomes .count, and -p_sect[i][1] becomes
.money.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agobudget: Fix military count (but not yet their pay)
Markus Armbruster [Sat, 18 Jun 2016 12:57:45 +0000 (14:57 +0200)]
budget: Fix military count (but not yet their pay)

When we add up military payroll, we discard fractions.  Payroll is
therefore lower than it should be, but I'm not fixing that now.  The
number of military budget reports is actually computed from payroll,
and therefore also low.

The obvious way to fix that would be adding another out parameter to
tax() and upd_slmilcosts().  However, budget and the update track cost
and count of numerous things (sector products, unit maintenance and
building, ...), and it's time for a common way to do that.

Create struct budget_item for tracking cost and count, and struct
budget nat_budget[MAXNOC] for tracking a nation's budget.  Track only
military for now; more to follow.

This fixes the military count.  The cost of military remains low,
because we discard fractions exactly as before.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate: Clean up upd_slmilcosts()
Markus Armbruster [Sat, 18 Jun 2016 12:48:24 +0000 (14:48 +0200)]
update: Clean up upd_slmilcosts()

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoinclude: Merge distribute.h into update.h
Markus Armbruster [Sat, 18 Jun 2016 12:03:38 +0000 (14:03 +0200)]
include: Merge distribute.h into update.h

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoinclude: Move update stuff from prototypes.h to update.h
Markus Armbruster [Sat, 18 Jun 2016 11:55:44 +0000 (13:55 +0200)]
include: Move update stuff from prototypes.h to update.h

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoinclude: Rename budg.h to update.h
Markus Armbruster [Sat, 18 Jun 2016 11:26:02 +0000 (13:26 +0200)]
include: Rename budg.h to update.h

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoinclude: Drop update.h
Markus Armbruster [Sat, 18 Jun 2016 11:08:35 +0000 (13:08 +0200)]
include: Drop update.h

update.h is a convenience header to include headers commonly needed in
update code.  The price for the convenience is superfluous recompiles.
Include necessary headers directly, and drop update.h

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agodoc/xdump: Fix definition of identifier in grammar
Markus Armbruster [Mon, 13 Jun 2016 19:58:49 +0000 (21:58 +0200)]
doc/xdump: Fix definition of identifier in grammar

getid() requires identifiers to start with a letter.  Fix the
documentation to match the code.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate: Drop do_feed()'s return value
Markus Armbruster [Sun, 17 Jul 2016 09:29:35 +0000 (11:29 +0200)]
update: Drop do_feed()'s return value

Call callers assign the return value to sp->sct_avail now.  Move the
assignment to do_feed() and drop the return value.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate: Fix avail roll over for stopped or broke sectors
Markus Armbruster [Fri, 8 Jul 2016 05:30:51 +0000 (07:30 +0200)]
update: Fix avail roll over for stopped or broke sectors

People don't work when their sector is stopped or their nation is
broke.  Implemented by produce_sect() skipping the assignment of new
work returned by do_feed() to sct_avail.

This is wrong because it lets all old work roll over, ignoring
rollover_avail_max.

Broken in 4.0.0.  Similarly broken for sectors disabled via zero
budget priority between a botched fix for changing sector types in
Chainsaw and the removal of budget priorities in commit 520446e,
v4.3.6.

Fix by zapping available work when the sector is stopped or its owner
is broke.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate: Limit avail roll over to about half the update's work
Markus Armbruster [Sun, 12 Jun 2016 10:48:05 +0000 (12:48 +0200)]
update: Limit avail roll over to about half the update's work

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>
5 years agoupdate: Round the people's work randomly rather than down
Markus Armbruster [Sun, 12 Jun 2016 12:26:29 +0000 (14:26 +0200)]
update: Round the people's work randomly rather than down

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>
5 years agosubs: Drop unused islist()
Markus Armbruster [Sun, 12 Jun 2016 10:12:05 +0000 (12:12 +0200)]
subs: Drop unused islist()

Unused since commit 6c927dc, v4.3.20.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoempobj: Drop unused get_empobj_mob_max()
Markus Armbruster [Sun, 12 Jun 2016 10:10:47 +0000 (12:10 +0200)]
empobj: Drop unused get_empobj_mob_max()

Unused since commit 3a1577a, v4.3.30.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoinclude: Bury dead remnants of TREATIES and SAIL
Markus Armbruster [Sun, 12 Jun 2016 10:06:34 +0000 (12:06 +0200)]
include: Bury dead remnants of TREATIES and SAIL

Left behind by commit a109de9 and commit dc73207, v4.3.33.

While there, drop a declaration of nonexistent function xedit() that
crept into commit afa65c8, v4.2.20.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoconfig: Make plains build and mobility cost match wilderness
Markus Armbruster [Sat, 11 Jun 2016 20:15:49 +0000 (22:15 +0200)]
config: Make plains build and mobility cost match wilderness

Wilderness costs nothing to build (since Chainsaw 3), but efficiency
doesn't affect their mobility cost of 0.4 (commit 083003a, v4.3.6).

Plains (since 4.2.0) cost the customary $100, and mobility cost drops
from 0.4 at 0% to 0.2 at 100% efficiency.

Change plains to match wilderness: waive build cost, set mob1 to 0.4

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agocollect: Derive collection value from power value
Markus Armbruster [Sat, 11 Jun 2016 19:30:52 +0000 (21:30 +0200)]
collect: Derive collection value from power value

The collection value of a sector is

    sector value = sector type value * (sector efficiency + 100)
                 + sum of item values
    item value = item type value * amount

The sector and item type values are configurable.

The item type collect values aren't too far off the power values:

    uid mnem  pow val pow/val
      0  "c"   50   1   50
      1  "m"  100   0  inf
      2  "s"  125   5   25
      3  "g"  950  60   15.8
      4  "p"    7   4    1.75
      5  "i"   10   2    5
      6  "d"  200  20   10
      7  "b" 2500 280    8.9
      8  "f"    0   0  NaN
      9  "o"   50   8    6.25
     10  "l"   20   2   10
     11  "h"   40   4   10
     12  "u"   50   1   50
     13  "r"   50 150    0.33

The power value is very roughly ten times the collect value, except
for civilians and uw it's 50, for rads its 0.33, and military are free
to collect.  The latter two make no sense.

Replace the item type collect value by the power value / 50 for
people, and by the power value / 10 for everything else.  This makes
collecting military, shells, guns and uw more expensive, and petrol,
bars, iron, oil and rads cheaper.

The sector type values are basically arbitrary.  For instance, an iron
mine costs five times as much as a wilderness, but a third of an
uranium mine, regardless of actual resource contents.

Replace this by different arbitrary values:

    sector value = (item value of materials necessary to build it
                    + build cost) * efficiency / 100
 + sector type maximum population
                 + sum of item values

Some sector types become cheaper, some more expensive.

Drop sect-chr and item selector value.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agocollect: Don't permit confiscation of active capital
Markus Armbruster [Sat, 11 Jun 2016 14:45:39 +0000 (16:45 +0200)]
collect: Don't permit confiscation of active capital

The whole idea of a sector acquiescing to takeover by lawyers waving
loan documents "proving" it's rightfully theirs is pretty
preposterous.  But a capital giving itself up that way (and then
paying out half the nation's treasury on top) beggars belief.
Disallow it.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agocollect: Don't disclose sector value when it exceeds loan
Markus Armbruster [Sat, 11 Jun 2016 14:04:54 +0000 (16:04 +0200)]
collect: Don't disclose sector value when it exceeds loan

When collect refuses to confiscate a sector because it's value exceeds
the amount owed, it still tells the player the exact value.  Don't.
Don't give the player something for nothing.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate: Saner rounding of sector building money and work
Markus Armbruster [Tue, 7 Jun 2016 19:10:18 +0000 (21:10 +0200)]
update: Saner rounding of sector building money and work

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>
5 years agoupdate: Saner rounding of unit building money and work
Markus Armbruster [Tue, 7 Jun 2016 19:10:07 +0000 (21:10 +0200)]
update: Saner rounding of unit building money and work

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>
5 years agopower: Include sector maximum population in power factor
Markus Armbruster [Mon, 6 Jun 2016 05:55:09 +0000 (07:55 +0200)]
power: Include sector maximum population in power factor

Replace the term

    power value of materials and cost + 9

by

    power value of materials and cost + maximum population / 1000 * 8 + 1

The value of ordinary sectors (maximum population 1000) doesn't
change.  The stock game's mountains, plains and bridges are now worth
only 28% as much.

This concludes my tweaking of the power factor for now.  I tested it
with data from a real game (Hvy Metal II).  The effect is small: #5
overtakes #4, and the lead of #1 over #2 and #3 shrinks some.  Closer
analysis finds the following reasons.  The game had very expensive big
cities.  Valuing them correctly gives countries with many cities a
noticeable boost.  Planes are worth less than before, but the
difference is much larger for cheap planes.  Big piles of construction
materials are worth much less, and shells, guns and bars are worth
more.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agopower: Include sector materials and cost in power factor
Markus Armbruster [Mon, 6 Jun 2016 04:58:07 +0000 (06:58 +0200)]
power: Include sector materials and cost in power factor

Building sectors can make you rate *lower* on the power chart, because
the power factor treats all sectors the same, regardless of build
materials and cost.

To avoid that, replace the term

   efficiency / 10.0

by

   (power value of materials + power value of cost + 9)
   * efficiency/100.0

The value of ordinary sectors, which take no materials and cost $100,
doesn't change.  The stock game's fortress is now worth 80% more due
to its materials and higher cost.  The stock game's wilderness is
worth 10% less, because it costs nothing.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoconfig: Make work to build sectors configurable
Markus Armbruster [Sun, 5 Jun 2016 20:49:07 +0000 (22:49 +0200)]
config: Make work to build sectors configurable

Traditionally, building up 100% takes 100 work.  Make the work to
build configurable, via new sect-chr selector bwork, backed by new
struct dchrstr member d_bwork.  Keep the required work exactly the
same for now.

Tearing down sectors remains four times easier than building.

Clients that hardcode sector build work need to be updated.  Easy,
since build work is now exposed in xdump.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoconfig: Generalize sector build materials storage
Markus Armbruster [Sun, 5 Jun 2016 18:08:30 +0000 (20:08 +0200)]
config: Generalize sector build materials storage

Sectors require lcms and hcms to build.  The build materials are
exposed as sect-chr columns lcms, hcms (struct dchrstr members d_lcms,
d_hcms).  They are per point per point of efficiency.  In contrast,
unit build materials are defined for 100%.

We want to define build materials for 100% now, for flexibility and
consistency, and we want to optionally support more build materials in
the future.  Replace d_lcms and d_hcms by array member d_mat[], and
replace selectors lcms and hcms by selectors l_build and h_build.

This is an xdump compatibility break.  To provide the customary grace
period, we'd have to make selectors lcms and hcms virtual instead,
with value l_build / 100 and h_build / 100 rounded up, and deprecate
them.  Deities would have to avoid l_build and h_build values that
aren't multiples of 100 for this to work fully.  But we're not
bothering with maintaining xdump compatibility in this release.

Provide selectors for all other item types, to help clients prepare
for future additional materials.  Use CA_DUMP_ONLY to keep them out of
configuration tables until they actually work.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoconfig: Define sector build cost per 100% instead of 1%
Markus Armbruster [Sun, 5 Jun 2016 18:00:27 +0000 (20:00 +0200)]
config: Define sector build cost per 100% instead of 1%

Sector build cost is defined by sect-chr column build (struct dchrstr
member d_build).  It's the cost per point of efficiency.  In contrast,
unit build cost is defined for 100%, by ship-chr, plane-chr, land-chr,
nuke-chr column cost.

Switch sectors to cost per 100%, for flexibility and consistency:
replace struct dchrstr member d_build by d_cost, and replace selector
build by selector cost.  Naming it cost for consistency with units is
possible only because the previous commit made the name available.

This is an xdump compatibility break.  To provide the customary grace
period, we'd have to make selector build virtual instead, with value
bcost / 100 rounded up, and deprecate it.  Deities would have to avoid
bcost values that aren't multiples of 100 for this to work fully.  But
we're not bothering with maintaining xdump compatibility in this
release.

With bcost values that aren't multiple of 100, the cost of sector
building may have to be rounded.  On the one hand, the cost of sector
demolition has always been rounded up.  On the other hand, the cost of
producing stuff is rounded randomly.  For now, round up, because
rounding randomly would affect subsequent random rounding, and upset
the smoke test.

Fortunately, show se b already shows build costs per 100%, since
commit 48ff096, v4.3.23.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoconfig: Add sect-chr flags, replace cost by flag "deity"
Markus Armbruster [Sun, 5 Jun 2016 17:22:45 +0000 (19:22 +0200)]
config: Add sect-chr flags, replace cost by flag "deity"

Give sector types capability flags (dchrstr member d_flags), like
ship, plane, land unit and nuke types have.

Member d_cost is effectively a flag since the previous commit.
Replace it by capability flag "deity".  This is an xdump compatibility
break.  To provide the customary grace period, we'd have make selector
cost virtual instead, and deprecate it.  But we're not bothering with
maintaining xdump compatibility in this release.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agodesignate: Drop support for designate costing money
Markus Armbruster [Sun, 5 Jun 2016 17:08:19 +0000 (19:08 +0200)]
designate: Drop support for designate costing money

Chainsaw 3 added the designate cost along with extra build cost and
materials, and used both to make fortresses expensive.  Unlike build
cost and materials, the cost to designate didn't pass the test of
time: it was set to zero in Empire 2.  Get rid of it.

sect-chr selector cost and struct dchrstr member d_cost have to stay,
because they're still used to configure whether a sector may be
designated by players (see commit 8d792e1).

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoconfig: Split table sect-chr for legibility
Markus Armbruster [Sun, 5 Jun 2016 16:57:24 +0000 (18:57 +0200)]
config: Split table sect-chr for legibility

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agobudget: Oops on use of invalid bp map entries
Markus Armbruster [Sun, 17 Jul 2016 06:12:56 +0000 (08:12 +0200)]
budget: Oops on use of invalid bp map entries

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate: Drop redundant bp map updates and functions
Markus Armbruster [Sun, 5 Jun 2016 16:18:12 +0000 (18:18 +0200)]
update: Drop redundant bp map updates and functions

produce_sect() updates the bp map several times.  This is wasteful:
since only ship, plane and land unit building reads it, bp map writes
before the last one are never read.  Update it just once for every
sector.

The update for sectors that are stopped or whose owner is broke is the
only remaining use of bp_put_items().  Since available work must still
be unchanged there, we can replace it by bp_set_from_sect().

bp_get_item(), bp_put_item(), bp_get_items(), bp_get_avail() and
bp_put_avail() are now unused.  Drop them.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate: Use a scratch sctstr for unit repair simulation
Markus Armbruster [Sun, 5 Jun 2016 14:03:39 +0000 (16:03 +0200)]
update: Use a scratch sctstr for unit repair simulation

If player->simulation, shiprepair(), planerepair(), landrepair() must
use the bp map, and must not change game state.

Copy the sector to a scratch buffer, update it from the bp map, work
on the sector normally, then write back to the bp map.  This is
simpler and safer.

Since get_materials() loses its connection to the bp map, move its
declaration out of budg.h.

While there, drop an ancient debugging logerror() from landrepair().

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate: Don't use materials and work destroyed by che or plague
Markus Armbruster [Sun, 5 Jun 2016 13:35:57 +0000 (15:35 +0200)]
update: Don't use materials and work destroyed by che or plague

Update code shared with budget uses the bp map instead of the sector,
so that budget can track materials and work available in sectors for
ship, plane and land unit building without updating the sector file.
Unfortunately, the bp map can become stale during the update.

prepare_sects() doesn't update the bp map for sea sectors, unlike
budget's calc_all().  Instead, we rely on calloc()'s initialization.
Works, but is a bit unclean.

prepare_sects() updates the bp map after fallout, but neglects to
update it for any of the later sector updates (steps 1b to 1f in info
Update-sequence).  Che can destroy materials and available work, and
the plague can kill military.  The bp map stays out of date until
produce_sect() updates it again.

Since we deal with sector production and countries in increasing order
of country number, foreign ships, planes and land units owned by
countries with lesser numbers get built before their sector produces.
Building uses the stale bp map then, and can use materials and
available work destroyed by che or the plague.  The update test
demonstrates the former case.

For stopped sectors or when the owner is broke, produce_sect() updates
only materials in the bp map, not available work.  Nothing builds in a
stopped sector, but allies may build in your sectors even when you're
broke.  They can use available work destroyed by che then.

Screwed up when Empire 3 made the update code work for budget.

Note that budget bypasses the flawed code: it prepares its bp map
itself instead of calling prepare_sects().

Rather than fixing prepare_sects(), use a null bp map for the update:
writes become no-ops, and reads read from the underlying sector.  Not
only does this remove the possibility of the bp map going stale during
the update, it saves a bit of memory, too.

calloc()'s initialization is now dead.  Switch to malloc().

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate/bp: bp_ref() is trivial, inline it
Markus Armbruster [Sun, 5 Jun 2016 13:19:01 +0000 (15:19 +0200)]
update/bp: bp_ref() is trivial, inline it

Trivial since commit a0fa455, v4.3.12.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate/ship: Don't let stopped sectors repair foreign ships
Markus Armbruster [Sun, 5 Jun 2016 13:13:11 +0000 (15:13 +0200)]
update/ship: Don't let stopped sectors repair foreign ships

Stopping a sector disables repairs of own ships completely.  Foreign
ships, however, repair just fine, consuming the sector's materials
and, if it's a harbor, its available work.

Disable repair of all ships in stopped sectors.  This is consistent
with plane and land unit repair.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate: Reorder ship, plane, land repair code for consistency
Markus Armbruster [Sun, 5 Jun 2016 13:00:42 +0000 (15:00 +0200)]
update: Reorder ship, plane, land repair code for consistency

No functional change.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate: Fix unowned uw to eat, procreate and produce
Markus Armbruster [Sun, 5 Jun 2016 12:37:41 +0000 (14:37 +0200)]
update: Fix unowned uw to eat, procreate and produce

produce_sect() skips sectors without civilians, military and land
units.  These are unowned.  Any uw there are frozen in time: they
don't eat, procreate or produce.  Has always been broken.  Don't skip
such sectors.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agobudget: Fix level prod. forecast when required level is too low
Markus Armbruster [Sun, 5 Jun 2016 10:15:58 +0000 (12:15 +0200)]
budget: Fix level prod. forecast when required level is too low

When the required level is too low for production, produce() returns
early.  Except when simulating.  Messed up when Empire 3 made the
update code work for budget.

This can make budget show level production even when it's not actually
possible.  In the stock game, this can happen for tech and research,
which require education > 5.0.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate: Fix income and level use after revolt or revert to deity
Markus Armbruster [Sat, 4 Jun 2016 15:59:52 +0000 (17:59 +0200)]
update: Fix income and level use after revolt or revert to deity

prepare_sects() caches the sector owner's getnatp() across
guerrilla(), do_plague() and populace().  This is wrong, because the
owner may change.  The mistake can be traced back all the way back to
BSD Empire 1.1.

If the sector revolts or reverts to deity, the ex-owner still receives
taxes and bank interest.  The update test demonstrates this bug.

If the sector revolts, we use the ex-owner's instead of the owner's
tech and research for plague, and we use the ex-owners happiness and
required happiness instead of the owner's for loyalty update and civil
unrest.

Change do_plague() and populace() to call getnatp() themselves.  Call
it in prepare_sects() only after we're done messing with the sector
owner.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate: Lift populace() from tax into prepare_sects()
Markus Armbruster [Sat, 4 Jun 2016 15:56:41 +0000 (17:56 +0200)]
update: Lift populace() from tax into prepare_sects()

This way, tax() is more focused, and populace() doesn't need to be
guarded with !player->simulation.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agosubs: Oops on makelost() / makenotlost() with no owner
Markus Armbruster [Sat, 4 Jun 2016 15:38:25 +0000 (17:38 +0200)]
subs: Oops on makelost() / makenotlost() with no owner

This catches bogus entries in the "lost" file like the ones fixed in
the previous commit.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate: Fix revert to deity and "no civilians" corner cases
Markus Armbruster [Sat, 4 Jun 2016 15:36:24 +0000 (17:36 +0200)]
update: Fix revert to deity and "no civilians" corner cases

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>
5 years agosect: Fix revert to deity and "no civilians" corner cases
Markus Armbruster [Sat, 4 Jun 2016 15:14:25 +0000 (17:14 +0200)]
sect: Fix revert to deity and "no civilians" corner cases

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.

When a deserted sector reverts to the deity, sct_prewrite() clears
owner and mobility.  It neglects to clear the old owner, unlike
populace().  Harmless, but fix it anyway for consistency.  Visible in
tests/navi-march/final.xdump.

Work percentage, loyalty and old owner apply to civilians.  When there
are none, sct_prewrite() sets work percentage to 100 and old owner to
owner.  It neglects to clear loyalty, unlike populace().  Loyalty
persists until populace() clears it.  Most of the time, this doesn't
matter, as moving civilians into a sector without civilians ignores
the sector's loyalty.  However, airlifted and unloaded civilians adopt
the sector's loyalty (bug#49 and bug#255).

Fix sct_prewrite() to clear loyalty for consistency, and to mitigate
these bugs.

Note that populace() may not always clear loyalty right away.  This
will be fixed in the next commit.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agosect: Keep work percentage without civilians at 100%
Markus Armbruster [Sat, 4 Jun 2016 12:32:58 +0000 (14:32 +0200)]
sect: Keep work percentage without civilians at 100%

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>
5 years agoneweff prod work: Use update code instead of duplicating it
Markus Armbruster [Sat, 4 Jun 2016 08:55:44 +0000 (10:55 +0200)]
neweff prod work: Use update code instead of duplicating it

The code to build sectors got quadruplicated in Chainsaw.  We've since
fixed numerous inconsistencies, but still have four copies of the
code.  Thanks to the recent work on upd_buildeff(), we can now use it
to replace the other three copies.  Rename it back to to buildeff()
while there.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoneweff production: Consider insufficient food
Markus Armbruster [Sat, 4 Jun 2016 07:50:09 +0000 (09:50 +0200)]
neweff production: Consider insufficient food

newe() and prod() duplicate parts of the update's do_feed(), except
they round babies down instead of randomly, to get a stable,
conservative forecast.  Unlike the update, they assume sufficient
food.  Inaccurate for sectors that are going to starve or have
suboptimal population growth.  Not documented.  Has always been that
way.

Eliminate the undocumented assumption by replacing the duplicate code
by a call of do_feed().  Add a suitable parameter to do_feed() to
preserve the different rounding.

The update test shows the improvement.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate: Drop redundant produce() parameters desig, neweff
Markus Armbruster [Sat, 4 Jun 2016 06:56:57 +0000 (08:56 +0200)]
update: Drop redundant produce() parameters desig, neweff

Its caller passes sp->sct_type and sp->sct_effic, so use that.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate: Drop upd_buildeff() parameter desig
Markus Armbruster [Sat, 4 Jun 2016 06:50:40 +0000 (08:50 +0200)]
update: Drop upd_buildeff() parameter desig

Since changing *sp is safe now, we can move the update of
sp->sct_type into upd_buildeff(), and drop the parameter.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate: Make upd_buildeff() return cost, drop parameter
Markus Armbruster [Sat, 4 Jun 2016 06:24:54 +0000 (08:24 +0200)]
update: Make upd_buildeff() return cost, drop parameter

Since changing *sp is safe now, we can move the update of
sp->sct_effic into upd_buildeff().  This frees the return value; use
it to return cost, and drop the parameter.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate: Drop produce() return value and parameters work, amount
Markus Armbruster [Sat, 4 Jun 2016 06:12:12 +0000 (08:12 +0200)]
update: Drop produce() return value and parameters work, amount

Since changing *sp is safe now, we can move the update of
sp->sct_avail into produce().  This frees the return value; use it to
return the amount produced.  Drop the parameters.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate: Drop upd_buildeff() parameter workp
Markus Armbruster [Sat, 4 Jun 2016 06:07:03 +0000 (08:07 +0200)]
update: Drop upd_buildeff() parameter workp

Since changing *sp is safe now, we can move the update of
sp->sct_avail into upd_buildeff(), and drop the parameter.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate: Move work percentage update into do_feed()
Markus Armbruster [Sat, 4 Jun 2016 05:30:40 +0000 (07:30 +0200)]
update: Move work percentage update into do_feed()

Since changing *sp is safe now, we can move the update of sp->sct_work
into do_feed(), use the return value for work, and drop parameter
workp.

The sp->sct_avail update looks similar, but there's a subtle
difference: it's skipped when the sector is stopped or its owner is
broke.  The caller already checks that, so leave the update there.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate: Drop produce_sect() variable neweff
Markus Armbruster [Fri, 3 Jun 2016 19:24:48 +0000 (21:24 +0200)]
update: Drop produce_sect() variable neweff

Since changing *sp is safe now, we can update sp->sct_effic
unconditionally, and eliminate neweff.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate: Drop unnecessary "not simulation" guards
Markus Armbruster [Fri, 3 Jun 2016 21:09:56 +0000 (23:09 +0200)]
update: Drop unnecessary "not simulation" guards

Since changing *sp is safe now, we can update sp->sct_work,
sp->sct_loyal, sp->sct-che unconditionally in do_feed(), and likewise
sp->sct_item and sp's resource in produce().

Output of budget in smoke test and update test changes slightly,
because it now executes more code, and the PRNs this consumes affect
random rounding.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate: Drop redundant upd_buildeff() parameter vec[]
Markus Armbruster [Fri, 3 Jun 2016 19:14:49 +0000 (21:14 +0200)]
update: Drop redundant upd_buildeff() parameter vec[]

Its caller passes sp->sct_item, so use that.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate: Drop redundant produce() parameter vec[]
Markus Armbruster [Fri, 3 Jun 2016 19:11:25 +0000 (21:11 +0200)]
update: Drop redundant produce() parameter vec[]

Its caller passes sp->sct_item, so use that.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate/human: Drop redundant parameters vec[]
Markus Armbruster [Fri, 3 Jun 2016 19:07:10 +0000 (21:07 +0200)]
update/human: Drop redundant parameters vec[]

All callers of growfood(), trunc_people() and grow_people() pass
sp->sct_item, so use that.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate: Drop redundant do_feed() parameter vec[]
Markus Armbruster [Fri, 3 Jun 2016 19:03:19 +0000 (21:03 +0200)]
update: Drop redundant do_feed() parameter vec[]

Its caller passes sp->sct_item, so use that.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate: Drop redundant bp_put_items() parameter vec[]
Markus Armbruster [Fri, 3 Jun 2016 18:58:54 +0000 (20:58 +0200)]
update: Drop redundant bp_put_items() parameter vec[]

All its callers pass sp->sct_item, so use that.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate: Use a scratch sctstr for production simulation
Markus Armbruster [Fri, 3 Jun 2016 18:49:05 +0000 (20:49 +0200)]
update: Use a scratch sctstr for production simulation

If player->simulation, produce_sect() must not change game state,
except for sct_updated.  To avoid changing sectors, it copies each
sector's sct_item[] to a scratch buffer, and tracks new designation,
efficiency and available work in local variables.

Copy the complete sector to a scratch buffer instead.  This is safer,
and will permit code simplifications.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate: Eliminate produce_sect()'s getnatp()
Markus Armbruster [Fri, 3 Jun 2016 18:24:04 +0000 (20:24 +0200)]
update: Eliminate produce_sect()'s getnatp()

Make callers pass struct natstr * instead of a country number.  All
callers have it already.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate: Fix work inconsistency with neweff, production
Markus Armbruster [Wed, 1 Jun 2016 20:37:28 +0000 (22:37 +0200)]
update: Fix work inconsistency with neweff, production

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>
5 years agoupdate: Enforce sector population limit only right after growth
Markus Armbruster [Wed, 1 Jun 2016 20:05:41 +0000 (22:05 +0200)]
update: Enforce sector population limit only right after growth

The update kills people to enforce sector population limits, right
after growing people.

However, the population limit may decrease between that killing and
the end of the update:

* Research declines (only with RES_POP), but the lower population
  limit isn't enforced.  Even with an insanely fast decline of 60%
  (level_age_rate = 1, etu_per_update = 60), the population limit
  decreases by less than 10%.

  Not applying the new level to this update is consistent with how we
  use levels elsewhere.

* upd_buildeff() changes sector type and efficiency, but a lower new
  population limit is enforced only when this changes the sector type
  from big city to not big city (since option BIG_CITY was added in
  Empire 2).

  It isn't enforced on other sector type changes.  Might change the
  population limit since the type's limit became configurable in
  commit 153527a (v4.2.20).  Sane configurations don't let players
  redesignate sectors to a type with different maximum population.
  The server doesn't enforce this, though.

  It isn't enforced when a big city's efficiency decreases, but sector
  type change isn't achieved.  Having population exceed the new limit
  without having produced enough work to change the type seems
  unlikely, as 25 will do even in the worst case, but should be
  possible with a sufficiently low work percentage.

  None of this is documented in info Update-sequence.  Inconsistent
  mess.  Drop it.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate neweff production: Limit work in big cities
Markus Armbruster [Wed, 1 Jun 2016 19:35:24 +0000 (21:35 +0200)]
update neweff production: Limit work in big cities

Civilians, military and uw work only up to their sector's population
limit.  The population limit depends on the sector type's maximum
population, research if RES_POP is enabled, and the sector's
efficiency for big cities.

The population limit may decrease between computation of work in
do_feed() and the end of the update:

* Research declines (only relevant with RES_POP).  Work is not
  corrected.  The declined research will apply at the next update.

  Since levels age after production is done, any work corrections
  could only affect leftover available work.  Wouldn't make sense.

  The effect is negligible anyway.  Even with an insanely fast decline
  of 60% (level_age_rate = 1, etu_per_update = 60), the population
  limit decreases by less than 10% in the worst case.

* upd_buildeff() changes sector type and efficiency.  Work is
  corrected only when this changes the sector type from big city to
  not big city.

  It isn't corrected on other sector type changes.  These can affect
  maximum population since the sector type's maximum became
  configurable in commit 153527a (v4.2.20).  Sane configurations don't
  let players redesignate sectors to a type with different maximum
  population.  The server doesn't enforce this, though.

  It isn't corrected when a big city's efficiency decreases, but
  sector type change isn't achieved.  Harmless, because tearing down a
  city takes very little work (25 for 100%), so efficiency decrease
  without type change means the work we have must be safely below any
  sane population limit's work.

Good enough.  However, the code implementing the work correction for
big cities is unclean.  Get rid of it by tweaking the rules: a big
city's extra population does not work.  City slickers, tsk, tsk, tsk.
At least they still pay their taxes.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoupdate: Avoid unnecessary inexactness in total_work()
Markus Armbruster [Wed, 1 Jun 2016 19:29:55 +0000 (21:29 +0200)]
update: Avoid unnecessary inexactness in total_work()

Commit 5ba8cab (v4.2.20) replaced milit * 2 / 5.0 by milit * 0.4.  Not
so smart; 0.4 isn't exact.  Go back to milit / 2.5.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agotests: Make update robust against variations in PRNG use
Markus Armbruster [Sun, 5 Jun 2016 12:36:15 +0000 (14:36 +0200)]
tests: Make update robust against variations in PRNG use

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>
5 years agoindent-emp: Take files to indent from command line
Markus Armbruster [Tue, 31 May 2016 19:34:33 +0000 (21:34 +0200)]
indent-emp: Take files to indent from command line

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agols-sources.pl: Fix for directory relative to root of tree
Markus Armbruster [Tue, 31 May 2016 19:28:00 +0000 (21:28 +0200)]
ls-sources.pl: Fix for directory relative to root of tree

Given and argument like tests/xdump, the script looks for
tests/xdump/.git, tests/.git, /.git.  The last one is wrong.  Make it
look for ./.git then.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agonsc: Expose generalized build materials in xdump and conditionals
Markus Armbruster [Mon, 30 May 2016 21:43:10 +0000 (23:43 +0200)]
nsc: Expose generalized build materials in xdump and conditionals

Ship, plane, land unit and nuke types require lcms and hcms to build.
Planes also require military, and nukes also require oil and rads.
These build materials are exposed as ship-chr, plane-chr, land-chr,
nuke-chr selectors l_build, h_build, crew, o_build, r_build.

We want to optionally support more build materials in the future.  To
help clients prepare for that, provide selectors for all other item
types.  Use CA_DUMP_ONLY to keep them out of configuration tables
until they actually work.

Rename selector crew to m_build for consistency.  This is an xdump
compatibility break.  We could easily add m_build and deprecate crew
to provide the customary grace period for such breaks.  However, more
xdump changes are coming down the pipe, and for some of them providing
a grace period wouldn't be as easy.  Ron Koenderink assures us WinACE
doesn't need a grace period.  So don't bother with maintaining xdump
compatibility in this release.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agonsc: New enum ca_dump member CA_DUMP_ONLY
Markus Armbruster [Mon, 30 May 2016 21:33:03 +0000 (23:33 +0200)]
nsc: New enum ca_dump member CA_DUMP_ONLY

CA_DUMP_ONLY selectors are like CA_DUMP_NONE, except the xdump command
still has them.  This will permit adding selectors for conditional
selector and xdump command forward compatibility without also adding
them to configuration tables.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agonsc: Replace NSC_EXTRA, NSC_CONST by enum ca_dump
Markus Armbruster [Sun, 29 May 2016 21:31:31 +0000 (23:31 +0200)]
nsc: Replace NSC_EXTRA, NSC_CONST by enum ca_dump

struct castr ca_flag NSC_EXTRA was introduced in commit 3e5c064
(v4.2.18) to permit selectors that aren't in xdump.

Flag NSC_CONST was introduced in commit 445dfec, and put to use in
commit d8422ca (both v4.3.0) to protect certain table elements that
should not be changed in customized tables.

Both flags apply only to xdump, not to other uses of struct castr,
such as conditionals.

Combining NSC_EXTRA | NSC_CONST makes no sense.

I'll shortly need a way to keep selectors out of configuration tables
for conditional selector and xdump command forward compatibility.
Doing it as a third flag would add more nonsensical combinations.

Convert the flags to a separate enum ca_dump instead:

    neither   -> CA_DUMP
    NSC_CONST -> CA_DUMP_CONST
    NSC_EXTRA -> CA_DUMP_NONE

Bonus: unlike the flags it replaces, ca_dump is not visible in xdump.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agonsc: Correct element type in NSC_IELT()
Markus Armbruster [Sun, 29 May 2016 20:58:37 +0000 (22:58 +0200)]
nsc: Correct element type in NSC_IELT()

Commit 9989c5b (v4.2.14) switched item storage from unsigned short to
short, but missed a type cast in the offset computation for
distribution and delivery selectors.  Offset computation was factored
out into NSC_IELT() in commit 4366c5a (v4.2.15).  Correct it there.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agodoc/xdump: Document hidden flag
Markus Armbruster [Sun, 29 May 2016 16:08:25 +0000 (18:08 +0200)]
doc/xdump: Document hidden flag

Missed in commit 41f00fd, v4.3.33.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agobomb: Simplify after previous commit
Markus Armbruster [Sun, 29 May 2016 10:16:25 +0000 (12:16 +0200)]
bomb: Simplify after previous commit

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agobomb: Eliminate bombcomm[], it's redundant
Markus Armbruster [Sun, 29 May 2016 10:14:05 +0000 (12:14 +0200)]
bomb: Eliminate bombcomm[], it's redundant

bombcomm[] used to contain the commodities that can be p-bombed.  In
BSD Empire 1.1, it contained I_SHELL, I_GUN, I_MILIT, I_PETROL, I_OIL,
I_RAD.  In Chainsaw, it contained either everything or everything but
I_BAR, depending on option preprocessor symbol SUPER_BARS.  When
Empire 2 replaced the compile time variable SUPER_BARS by the run time
variable opt_SUPER_BARS, bombcomm[] became a redundant indirection.
Eliminate it.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agobomb: Don't list bombable commodities on invalid selection
Markus Armbruster [Sun, 29 May 2016 09:58:32 +0000 (11:58 +0200)]
bomb: Don't list bombable commodities on invalid selection

comm_bomb() first lists commodities that can be bombed and are
present, then prompts for the one to bomb.  If the player selects a
bomb-proof one, it rejects it, lists the bombable ones, and prompts
again.  This can only happen when option SUPER_BARS is enabled, and
the player selects bars.  Looks like this:

    Bomb what? (ship, plane, land unit, efficiency, commodities) c
    some civilians
    some military
    commodity to bomb? b
    You can't bomb bars of gold!
    Bombable: civilians, military, shells, guns, petrol, iron ore, dust (gold), food, oil, light products, heavy products, uncompensated workers, radioactive materials
    commodity to bomb?

The list is of marginal value.  It was more useful back when
comm_bomb() didn't list commodities before prompting (BSD Empire 1.1).
It's also illegible.  Drop it.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoplnsub: Let crewless planes spread the plague, too
Markus Armbruster [Sat, 28 May 2016 17:21:12 +0000 (19:21 +0200)]
plnsub: Let crewless planes spread the plague, too

Commit 612ec62 (v4.3.31) made plane crew and cargo spread the plague.
This requires looking for crew in build materials.  Awkward if we ever
permit non-military crew.

Simply drop the "has crew" condition.  If a plane's cargo can spread
it, then servicing and refueling the plane can spread it, too.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agotransport: Don't hardcode material weights
Markus Armbruster [Sat, 28 May 2016 14:21:08 +0000 (16:21 +0200)]
transport: Don't hardcode material weights

tran_plane() computes a plane's weight from its materials.  It
hardcodes lcm weight 1, hcm weight 2, and military weight 0.  Use
ichr[].i_lbs instead, which is 1 in the stock game for all three
materials.

While there, support arbitrary materials, even though they aren't yet
possible, just to avoid unnecessary assumptions on possible build
materials.

Since the stock game's planes use fewer military than hcms, they
become up to 15% lighter, except for zep, which becomes 10% heavier.
Missiles use no military and become 20-33% lighter.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agopower: Include nukes in power factor, like other units
Markus Armbruster [Sat, 28 May 2016 05:42:36 +0000 (07:42 +0200)]
power: Include nukes in power factor, like other units

Building nukes makes you rate *lower* on the power chart, because the
power factor ignores nukes.  Fix that.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agopower: Saner power for items, ships, planes and land units
Markus Armbruster [Fri, 27 May 2016 15:41:45 +0000 (17:41 +0200)]
power: Saner power for items, ships, planes and land units

Items, ships, planes and land units all contribute to the power
factor, which determines position on the power chart.

Items are worth

    amount * item value * (0.5 + nation tech level / 1000.0)

The item values aren't quite right: producing stuff can *hurt* your
position on the power chart.  Food, uw and rads are worth nothng.

Reduce the value of oil, and give rads the same value as oil.  Tweak
value of iron and oil products so that production's power change is
roughly zero around p.e. 0.9 (tech 110), except for construction
materials, where it's zero at p.e. 0.5 (tech 0).  Construction
materials become less valuable, shells, guns and petrol become more
valuable.  Increase value of bars to roughly match the other changes.
It may still be too low.  Halve the value of civilians, and give the
other half to uw.  Results:

            old     new     change
    civ      100     50   / 2
    mil      100    100
    shell     80    125   * 1.5625
    gun      400    950   * 2.375
    pet        2      7   * 3.5
    iron      10     10
    dust     200    200
    bar     1000   2500   * 2.5
    food       0      0
    oil      100     50   / 2
    lcm      100     20   / 5
    hcm      200     40   / 5
    uw         0     50   new
    rad        0     50   new

Ships, planes and land units are worth

    base value * effic/100.0 * (0.5 + unit tech level / 1000.0)

For ships and land units, the base value is

    lcm/5.0 + hcm/5.0

Build cost is ignored, but lcms are valued twice as much "loose" ones
(before this commit).  Therefore, building stuff can change your
position on the power chart in both directions, depending on the type
of build.

For planes, the base value is

    20 * (0.5 + nation tech level / 1000.0)

Build cost and materials are ignored, and tech is squared.  This
is plainly absurd.

Unify to

    (power value of money and materials to build) * effic/100.0

This formula is chosen so that building stuff doesn't change your
power factor.  Bonus: it doesn't assume anything about possible build
materials.

For ships and land units, factoring in build cost overcompensates the
discounted value of construction materials more often than not.

Noteworthy changes for the stock game:

    ship type          old     new    change
    ss   slave ship     20     5.8    * 0.29    largest decrease
    cs   cargo ship     20     7.8    * 0.39
    ts   trade ship     60    25.5    * 0.42
    frg  frigate        12     7.8    * 0.65
    bb   battleship     24    21.8    * 0.91
    cal  light carrier  22    30.4    * 1.38
    can  nuc carrier    30    84.6    * 2.82    largest increase

    land unit type     old     new    change
    hat  hvy artillery  12     9.6    * 0.8     largest decrease
    linf light infantry  2.4   3.32   * 1.38
    cav  cavalry         3     5.4    * 1.8
    inf  infantry        3     5.4    * 1.8
    lar  lt armor        3     6.4    * 2.13
    com  commando        3    15.4    * 5.13
    eng  engineer        3    30.4    * 10.13
    meng mech engineer   3    45.4    * 15.13   largest increase

For planes, the power value change depends on the type.  Below a
certain nation tech level, planes of this type become more valuable,
above less.

For the stock game, planes costing at most $1000 become less valuable
at any nation tech level that can build them, and planes costing at
least $1800 become more valuable at any practical tech level,
i.e. under 400.  Noteworthy planes:

    plane type                 new
    sam  Sea Sparrow           2.1              least valuable
    f2   P-51 Mustang          4.34
    lb   TBD-1 Devastator      5.92
    jf1  F-4 Phantom          10.6
    tr   C-56 Lodestar        10.78
    jt   C-141 Starlifter     15.86
    jhb  B-52 Strato-Fortress 33.54
    ss   KH-7 spysat          41.2              most valuable

The old value is a flat 12 at nation tech level 100, 15 at tech level
250, and 18 at tech level 400.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoshow: Extend show item to show the power value
Markus Armbruster [Fri, 27 May 2016 19:40:11 +0000 (21:40 +0200)]
show: Extend show item to show the power value

Also update "info power" to point to "show item" instead of the
formerly hardcoded values.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agopower: Make item power value configurable
Markus Armbruster [Fri, 27 May 2016 19:18:47 +0000 (21:18 +0200)]
power: Make item power value configurable

Custom games may want to tweak how items contribute to the power
factor, in particular when products are also customized.  Add ichrstr
member i_power and item selector power for that.

"info power" doesn't reflect this change, yet.  It'll be updated in
the next commit.

The current item power values are problematic.  This will be addressed
later.

For straightforward configurations, reasonable item power values could
perhaps be derived from the configuration automatically.  However,
this is surprisingly hard in the general case: since producing things
should not decrease power, the efficiency of processing products into
other products needs to be considered, and estimating these
efficiencies can be difficult.

Deities can create multiple products making the same item, or multiple
sector types with the same product, but different process efficiency
(sect-chr selector peffic).  Providing differently efficient ways to
make the same item can be reasonable when the sector types involved
have different terrain.  To average them, you'd need to know the map.

The stock game has one example: gold mines produce dust with 100%
process efficiency, mountains produce it with 75%.  Mountains are
normally rare enough not to matter.

Level p.e. (product selectors nlmin, nllag) may have to be considered.
In the stock game, level p.e. variations are minor, because it reaches
0.9 pretty quickly.  In games where it doesn't, you might have to
increase the power value of the product.

Resources (sect selectors min, gold, fert, ocontent, uran) and
resource depletion (product selectors nrndx and nrdep) further
complicate things: you might want to increase the power value of
products depending on unusually scarce resources, but you can't know
what's scarce without understanding the map.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agopower: Use ship, plane, land unit tech instead of nation's
Markus Armbruster [Fri, 27 May 2016 18:08:39 +0000 (20:08 +0200)]
power: Use ship, plane, land unit tech instead of nation's

Actual abilities of ships, planes and land units depend almost
completely on the individual unit's tech, not the nation's tech.  The
power factor should reflect that.

The power value of a unit is of the form

    base value * (20 + nation's tech level) / 500

Change it to

    base value * (20 + unit's tech level) / 500

Note that a plane's base value still depends on the nation's tech
level.  This commit merely makes the absurdity stand out a bit more.
To be fixed later.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agopower: Saner power value for tech, particularly at low tech
Markus Armbruster [Fri, 27 May 2016 17:58:58 +0000 (19:58 +0200)]
power: Saner power value for tech, particularly at low tech

In the old times, power didn't consider tech at all.  Chainsaw's
option NEWPOWER (mandatory since v4.2.14, on by default before)
changed this dramatically: the power factor gets multiplied by
max(1, tech) / 500.

In the early game, small absolute tech differences yield large power
factor differences.  For instance, if country A has tech level 10, and
B has 5, then A gets a factor two boost.

As the game progresses, tech differences between viable countries tend
to grow, but only slowly.  The influence on power diminishes.  For
instance, if C has tech level 270 and D has 240 (quite a respectable
tech lead), then C gets a modest 1.125x boost over D.

Change the factor to (20 + tech) / 500.  Now A's advantage is only
1.2, and C's is 1.115.

You might think that's rather low.  However, tech is not power unless
you project it, and then it manifests itself as sectors, population
and other stuff power counts.

The same tech term occurs in plane power, except with just tech
instead of max(1, tech) .  Change it there as well, for consistency.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoinfo/power: Rewrite power formula for clarity
Markus Armbruster [Fri, 27 May 2016 15:36:35 +0000 (17:36 +0200)]
info/power: Rewrite power formula for clarity

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agopower: Drop the RES_POP factor
Markus Armbruster [Fri, 27 May 2016 14:58:04 +0000 (16:58 +0200)]
power: Drop the RES_POP factor

If option RES_POP is enabled, the power factor is multiplied by a
"research factor" of 1.0 + maxpop / 10000.0, where maxpop is the
maximum population of a mine sector.

Back when this code was written (Chainsaw 3), all sectors had the same
population limit, so using a mine sector was as good as any.  Since
then, it has become configurable, and the stock game has both sector
types with lower (mountains, plains) and with higher (cities)
population limits.

Space for people is worth considering for power, but multiplying total
power by a fudge factor based on the most common sector type's maximum
population is silly.  Drop it.

Adjusting each sector's value for maximum population would make more
sense, with and without RES_POP.  Perhaps later.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agopower: Simplify tallying the power value of items
Markus Armbruster [Fri, 27 May 2016 13:42:17 +0000 (15:42 +0200)]
power: Simplify tallying the power value of items

Item power value is basically number of items times the item power
weight.  For some item types, we add up the item numbers, then apply
the weight.  For lcms and hcms, we apply the weight, then add up the
weighted numbers.

Adopt the latter method for all types: change addtopow() to tally the
power value for all types instead of just lcms and hcms, and drop
gen_power()'s item power value computation.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoconfig: Generalize unit build materials storage
Markus Armbruster [Fri, 27 May 2016 12:17:08 +0000 (14:17 +0200)]
config: Generalize unit build materials storage

Use a single array member instead of multiple scalar members.  Only
the array elements that replace scalar members are can be non-zero for
now.

This is a first step to permitting more build materials.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agoconfig: Make work to build units independently configurable
Markus Armbruster [Fri, 27 May 2016 11:39:11 +0000 (13:39 +0200)]
config: Make work to build units independently configurable

The work required for build and repairs is traditionally a function of
build materials: 20 + lcm + 2*hcm for ships, planes and land units,
and (lcm + 2*hcm + oil + rad)/5 for nukes.  Make it independently
configurable instead, via new ship-chr, plane-chr, land-chr, nuke-chr
selector bwork, backed by new struct mchrstr member m_bwork, struct
plchrstr member pl_bwork, struct lchrstr member l_bwork, struct
nchrstr member n_bwork.  Keep the required work exactly the same for
now.

Clients that compute work from materials need to be updated.  Easy,
since build work is now exposed in xdump.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
5 years agotests/update: New; exercises the update
Markus Armbruster [Tue, 28 Jun 2016 18:29:18 +0000 (20:29 +0200)]
tests/update: New; exercises the update

Notable gaps in its coverage are fallout, most of guerrilla, delivery,
distribution, ALL_BLEED and LOSE_CONTACT.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>