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 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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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_type into upd_buildeff(), and drop the parameter.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
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>
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_avail into upd_buildeff(), and drop the parameter.
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>
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>
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>
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>
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>
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>
... when referring to a function's parameter or a struct/union's
member.
The idea of using FOO comes from the GNU coding standards:
The comment on a function is much clearer if you use the argument
names to speak about the argument values. The variable name
itself should be lower case, but write it in upper case when you
are speaking about the value rather than the variable itself.
Thus, "the inode number NODE_NUM" rather than "an inode".
Upcasing names is problematic for a case-sensitive language like C,
because it can create ambiguity. Moreover, it's too much shouting for
my taste.
GTK-Doc's convention to prefix the identifier with @ makes references
to variables stand out nicely. The rest of the GTK-Doc conventions
make no sense for us, however.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
TREATIES has issues:
* Treaties can cover attack, assault, paradrop, board, lboard, fire,
build (s|p|l|n) and enlist, but not bomb, launch, torpedo and
enlistment centers.
* Usability is very poor. While a treaty is in effect, every player
action that violates a treaty condition triggers a prompt like this:
This action is in contravention of treaty #0 (with Curmudgeon)
Do you wish to go ahead anyway? [yn]
If you decline, the action is not executed. If you accept, it is.
In both cases, your decision is reported in the news.
You cannot get rid of these prompts until the treaty expires.
* Virtually nobody uses them.
* Virtually unused code is buggy code. There is at least one race
condition: multifire() reads the firing sector, ship or land unit
before the treaty prompt, and writes it back after, triggering a
generation oops. Any updates made by other threads while trechk()
waits for input are wiped out, triggering a seqno mismatch oops.
* The treaty prompts could confuse smart clients that aren't prepared
for them. WinACE isn't, but is reported to work anyway at least
common usage. Ron Koenderink (the WinACE maintainer) suspects there
could be a few situations where it will fail.
This feature is not earning its keep. Remove it. Drop command
treaty, consider treaty, offer treaty, xdump treaty, reject treaties.
Output of accept changed, obviously.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Code dealing with money mixes int and long pretty haphazardly.
Harmless, because practical amounts of money fit into int on any
machine capable of running the server. Clean up anyway.
meltitems() computes #items * etus per update * fallout in type long.
Theoretical maximum is ITEM_MAX * etus * FALLOUT_MAX = 99980001 *
etus. Can overflow 32 bits for etus > 21. Has been broken since the
introduction of fallout in KSU.
Compute the product in double instead.
