update.h is a more logical home for update_running than server.h.
Move the definition and the assignments along, from server/update.c to
lib/update/main.c.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The do_upd_checking recursion guard is superfluous: do_mob_sect()
doesn't call anything. Has been that way since MOB_ACCESS was added
in Empire 3.
Inline the remaining code of sct_do_upd_mob(), shp_do_upd_mob(),
pln_do_upd_mob(), lnd_do_upd_mob() in their only callers
sct_postread(), shp_postread(), pln_postread(), lnd_postread().
Rename do_mob_sect(), do_mob_ship(), do_mob_plane(), do_mob_land() to
mob_sect, mob_ship(), mob_plane(), mob_land() and give them external
linkage.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The update uses mob_sect(), mob_ship(), mob_plane() and mob_land() for
two related, but different jobs: to give the previous turn's remaining
MOB_ACCESS mobility, and to give this update's new mobility. The two
were probably conflated in an attempt to share code, but it actually
just complicates things.
Collect the MOB_ACCESS code in new function mob_access_all(), and the
normal mobility update code in new function mob_inc_all().
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
When option TECH_POP is enabled, the cost of tech increases when
civilian population exceeds 50000. Only civilians in old-owned
sectors count. This differs from education and happiness, where
civilians loaded on ships and land units count, too.
The update counts population for TECH_POP with count_pop(). This is
an extra pass over all sectors.
produce also uses count_pop(), once per tech center examined.
Wasteful.
budget avoids count_pop(): it uses tax()'s civilian count. More
efficient, but the difference to the update is ugly.
Change TECH_POP to use the same civilian count as education and
happiness, i.e. count civilians on ships and land units, too.
This count is available in nat_budget[] in time for produce(): it's
computed by tax() and by ship and land unit maintenance. So use it
there. This takes care of the update and budget. produce doesn't run
enough update code to do the same. Keep calling count_pop() there.
Update it to match the update, and give it internal linkage.
Duplicating update's workings there is ugly, so mark it FIXME.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
