Deliver fails to abandon sectors when it ships out all civilians and
military. The sector remains owned until the next non-update sector
update abandons it. Has always been broken.
Distribution had the same bug until commit d0f3847 (v4.3.20) fixed it.
Fix it the same way for delivery: adjust the amount moved to avoid
moving out the last civilian, or the last military if there are no
civilians.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
People in sectors get plagued, then taxed or paid, then fed. People
on ships and land units get paid, then fed, then plagued. Sectors
were messed up when Empire 3 made the update code work for budget.
Change sectors back to how they worked before Empire 3: move do_feed()
from produce_sect() to prepare_sects(), and delay do_plague() until
after do_feed(). People in sectors now get taxed, paid and fed even
when they die of the plague, just like they do on ships and land
units.
Because do_plague() now runs after populace(), the latter's handling
of people dying off doesn't cover plague anymore. Delay it to the
very end of prepare_sects().
Additionally, move feeding and plaguing from upd_ship(), upd_land() to
prep_ship(), prep_land(), for consistency with sectors.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Ship, plane and land unit repairs depend on and change the state of
the sector. To predict repairs, we need to predict the state of the
sector before repairs. The obvious way to do that is to simulate the
sector update and all ship, plane and land unit updates there in the
correct order.
Until recently, we simulated only own sectors, ships, planes and land
units. Wrong when foreign sectors, ships, planes or land units are
involved. The fix (commit 70f6964) makes budget simulate all
countries. Correct, but does much more work than necessary. With a
little effort, we can track what needs to be simulated.
Use the bp map for tracking. We need to mark the player's sectors and
all sectors where he has ships, planes or land units. Do the former
in bp_alloc(), and the latter in prep_ships(), prep_planes(),
prep_lands().
Skip sectors not so marked. This requires delaying prepare_sects()
until after prep_ships(), prep_planes(), prep_lands(). Their order
doesn't actually matter: prep_ships() & friends only spend money, and
nothing in preparation depends on whether the country is still
solvent.
Skip ships, planes and land units in sectors not so marked.
This speeds up budget by around a third in my testing, more for small
countries. Roughly 15% slower than before the fix for repairs abroad.
The update has to do a bit more work than before, but the performance
difference is lost in the noise.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Several headers define macros that use ef_ptr() without including
"file.h". Fix that. Drop redundant inclusions elsewhere.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The update visits sectors in increasing order of country number.
Within a country, it visits in increasing order of sector number,
which is effectively top to bottom, left to right, starting with
absolute 0,0.
The order doesn't actually matter. Before Chainsaw's option BUDGET,
the update simply visited the sectors in sector number order. Go back
to that order, because it's faster. For the update, it's a few
percent in my testing. For budget, it's more than a third.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The update visits ships, planes and land units in increasing order of
country number. Within a country, it visits first ships, then planes,
then land units, each in increasing order of unit number.
The order is relevant when money, materials and work don't suffice to
build everything.
Money is charged to the owner, so only the relative order for the same
owner matters there. One order is as good as any.
Work and materials come from the sector, so only the relative order in
each sector matters. The current order unfairly prefers countries
with lower country numbers. Mitigating factor: the affected countries
need to be friendly (ships only) or allied.
The unfairness goes back to Chainsaw's option BUDGET. See the commit
before previous for more detailed historical notes.
The update test demonstrates the unfair behavior: sector 14,6 builds
ships 95/97 owned by country#1, but not 96 owned by country#7.
Likewise, planes 95/96/97 and land units 95/96/97.
Go back to the the pre-BUDGET order: first ships, then planes, then
land units, all in increasing order of unit number, regardless of
owner.
The update test now builds ship, plane and land unit 96 instead of 97.
Bonus: speeds up both the update and budget by a similar absolute
amount. For budget, this is roughly a factor of two in my testing.
For the update, which does much more, it's around 10%.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The budget command simulates an update by running selected parts of
the update code. It skips parts that depend on hidden information
such as guerrilla warfare. For speed, it also skips parts it doesn't
need, such as distribution and foreign sectors, ships, planes and land
units.
Skipping foreign sectors is wrong when any of the player's ships,
planes or land units will be repaired in foreign sectors, because it
makes budget use old materials and work instead of new.
Skipping foreign ships, planes and land units is wrong when they
compete with the player's for materials and work.
The bug goes back to Chainsaw's option BUDGET. See the previous
commit for more detailed historical notes. The update test
demonstrates it in several variations.
Fix it with the sledgehammer: don't skip foreign sectors, ships,
planes and land units. This makes budget almost twenty times slower
in my testing. Probably tolerable on a reasonably beefy machine, but
we can do better; the next few commits will claw back most of the lost
performance.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Ship, plane and land unit repair uses new work, except in sectors
owned by countries with a higher country number.
This inconsistency is an artifact of how the update is sequenced: we
work on countries one after the other. A country's ships, planes and
land units get repaired before higher-numbered countries' sectors
produce. Any ship, plane and land unit repairs in such sectors use
old work instead of new work.
Repair work use changed several times during Empire's history.
In BSD Empire, repairs use old work, because it updates ships and
planes before sectors.
Chainsaw added budget priorities and the budget command as option
BUDGET. Budget priorities let players choose separately for ships,
planes and land units whether to use old or new work for repairs.
The option also changed the update to work on countries one after the
other, presumably to permit a more efficient implementation of the
budget command.
Chainsaw also introduced repairs in foreign sectors under option
ALLYHARBORWORK.
With BUDGET disabled, all repairs still use old work, whether at home
or abroad. With BUDGET enabled, work use of repairs at home depends
on budget priorities, but work use abroad depend on country numbers.
Both options became standard in Empire 2.
Since v4.3.6, repairs at home always use new work (commit 967299a and
commit 520446e).
To make repairs abroad always use new work as well, we need to update
all sectors before any ship repair. This is straightforward: split
the loop over countries between sectors and unit building. For
symmetry, also split it between unit maintenance and sectors.
The budget command is differently broken, and will be fixed next.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Land unit maintenance and building ignore land units in sanctuary
sectors. Leftovers from undocumented compile-time option START_UNITS,
which is gone since commit dab1f0b, v4.3.0. Feeding, paying military
and fallout don't ignore them. Change maintenance and building to
match.
Sector preparation (except for the fallout part) and production ignore
even non-sanctuary sectors owned by nations in sanctuary. Fallout,
delivery, distribution and mobility growth don't check the sector
owner's status. Change preparation and production to ignore just
sanctuary sectors, without checking the sector owner's status. Except
don't bother for most of fallout, as we already avoid spreading
fallout into sanctuaries; still ignore sanctuaries when doing fallout
damage mostly for completeness.
Delivery and distribution ignore unowned sectors. Ignore sanctuaries,
too.
Feeding and mobility growth ignore sanctuaries. Ignore sea, too.
None of this should matter in sane game states.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Split upd_slmilcosts() into prep_ships() and prep_lands(). Move the
sanity check for dead ships and land units from prod_ships() and
prod_lands() there. Move their call from prepare_sects() to its
caller, along with pay_reserve().
Create prep_planes() for symmetry. Pilots are now paid at the same
time as other military. Can matter only when the country goes broke
during the update.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
People in sectors first eat, then build the sector, then produce.
People in ships produce, eat, then build.
The starvation command can be off for fishing vessels, because it
doesn't consider the food they produce.
Change ships to match sectors. "Fixes" starvation. Fishing boats and
oil derricks being repaired at sea become a bit more productive.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
No maintenance is paid when the sector is stopped or the owner is
broke. Broken in commit 44c36fa, v4.3.23. Fix it.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
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>
Per-civilian happiness and education production is raw production
divided by the number of old-owned civilians. The update reports the
number of old-owned civilians ("total pop was %d").
This number of civilians is also used by budget to predict cost of
tech when option TECH_POP is enabled, but that doesn't match how the
update computes the cost. To be fixed next.
Civilians loaded on ships are only counted by the update, not by
budget. Harmless, as budget doesn't compute happiness and education.
Civilians loaded on land units are ignored by both. None of the stock
game's land units can load civilians.
Civilians in sectors are counted before plague deaths, and in ships
afterwards.
Fix upd_ship() and upd_land() to count civilians the same way as
prepare_sects() does for sectors.
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>
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>
Traditionally, unused unused available work is discarded at the
update. Since commit d7a054c (v4.2.13), deities can configure (some)
unused work to "roll over", i.e. available work = some unused work +
this update's work.
Not discarding unused work reduces micromanagement incentives.
However, it also leads to unobvious behavior.
For instance, here's the obvious way to build a radar station: move in
enough people to make 200 work. Half of it is available for sector
building, and increases efficiency to 100%. Here's a not-so-obvious
way: move in enough people to make 134 work. 67 will be used to
increase efficiency to 67%. Now move your workers elsewhere. The
unused available work is enough to finish the job at the next update.
Similarly, neighbors could be surprised by sectors building bridges
despite having no visible workers.
Commit 7f4e59f (v4.2.15) let deities limit the amount rolled over:
unused work above rollover_avail_max is discarded. This became the
default with a value of 50 in commit 81a3e4c4, v4.3.31.
Limit it further so that "roll over" can increase the update's work by
no more than half, plus one. The extra point is there so that even a
tiny work force has a chance to eventually eke out the second point of
work needed to increase efficiency.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Rounding work down can lead to a bit of work micromanagement. For
instance, four military on a lonely island accomplish nothing in 60
ETU updates, but five will make one point of work per update. They
can build a 2% harbor in four updates, as long as rollover_avail_max
is at least 3. Six to eight will be no faster.
The people's work used to be rounded randomly until Empire 3's big
effort to make the update code work for budget switched to rounding it
down, perhaps accidentally.
Switch back to rounding randomly, so that players don't have to get it
exactly right. Four military now get to 2% in five updates on
average, five in four, six or seven in three, and so forth.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
