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>
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>
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>
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>
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>
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>
Code dealing with counting people mixes int and long pretty
haphazardly. Harmless, because practical populations fit into int
easily on any machine capable of running the server. Clean up anyway.
Why upgrade? I'm not a lawyer, but here's my take on the differences
to version 2:
* Software patents: better protection against abuse of patents to
prevent users from exercising the rights under the GPL. I doubt
we'll get hit with a patent suit, but it's a good move just on
general principles.
* License compatibility: compatible with more free licenses, i.e. can
"steal" more free software for use in Empire. I don't expect to steal
much, but it's nice to have the option.
* Definition of "source code": modernization of some details for today's
networked world, to make it easier to distribute the software. Not
really relevant to us now, as we normally distribute full source code.
* Tivoization: this is about putting GPL-licensed software in hardware,
then make the hardware refuse to run modified software. "Neat" trick
to effectively deny its users their rights under the GPL. Abuse was
"pioneered" by TiVo (popular digital video recorders). GPLv3 forbids
it. Unlikely to become a problem for us.
* Internationalization: more careful wording, to harden the license
outside the US. The lawyers tell us it better be done that way.
* License violations: friendlier way to deal with license violations.
This has come out of past experience enforcing the GPL.
* Additional permissions: Probably not relevant to us.
Also include myself in the list of principal authors.
type. Make it abstract because that's possible. Change data layout
so that the slots belonging to a sector are together in memory, it's
nicer to the cache.
(bp): The new type. Users changed.
(get_wp): Update accordingly.
(alloc_bp): New.
(update_main, calc_all): Use it. Before, calc_all() allocated 1/7
more than necessary.
other. Ensure headers in include/ can be included in any order
(except for econfig-spec.h, which is special). New header types.h to
help avoid inclusion cycles. Sort include directives. Remove some
superflous includes.
This is safe, because the only caller passed a copy of the latter
created with getvec(), and populace() doesn't change it.
(tax): Replace getvec() by direct, read-only item access.
To save space, the ancients invented `variables': a collection of
key-value pairs, missing means zero value, space for `enough' keys.
This complicates the code, as assigning to a `variable' can fail for
lack of space. Over time, `enough' increased, and for quite some time
now `variables' have been *wasting* space. This changeset replaces
them, except in struct mchrstr, struct lchrstr and struct pchrstr,
where they are read-only, and will be replaced later. It is only a
first step; further cleanup is required. To simplify and minimize
this necessarily huge changeset, the new item[] arrays have an unused
slot 0, and the old variable types V_CIVIL, ... are still defined, but
must have the same values as the item types I_CIVIL, ...
