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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
