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>
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.
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>
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 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>
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>
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>
Items, ships, planes and land units all contribute to the power
factor, which determines position on the power chart.
Items are worth
amount * item value * (0.5 + nation tech level / 1000.0)
The item values aren't quite right: producing stuff can *hurt* your
position on the power chart. Food, uw and rads are worth nothng.
Reduce the value of oil, and give rads the same value as oil. Tweak
value of iron and oil products so that production's power change is
roughly zero around p.e. 0.9 (tech 110), except for construction
materials, where it's zero at p.e. 0.5 (tech 0). Construction
materials become less valuable, shells, guns and petrol become more
valuable. Increase value of bars to roughly match the other changes.
It may still be too low. Halve the value of civilians, and give the
other half to uw. Results:
old new change
civ 100 50 / 2
mil 100 100
shell 80 125 * 1.5625
gun 400 950 * 2.375
pet 2 7 * 3.5
iron 10 10
dust 200 200
bar 1000 2500 * 2.5
food 0 0
oil 100 50 / 2
lcm 100 20 / 5
hcm 200 40 / 5
uw 0 50 new
rad 0 50 new
Ships, planes and land units are worth
base value * effic/100.0 * (0.5 + unit tech level / 1000.0)
For ships and land units, the base value is
lcm/5.0 + hcm/5.0
Build cost is ignored, but lcms are valued twice as much "loose" ones
(before this commit). Therefore, building stuff can change your
position on the power chart in both directions, depending on the type
of build.
For planes, the base value is
20 * (0.5 + nation tech level / 1000.0)
Build cost and materials are ignored, and tech is squared. This
is plainly absurd.
Unify to
(power value of money and materials to build) * effic/100.0
This formula is chosen so that building stuff doesn't change your
power factor. Bonus: it doesn't assume anything about possible build
materials.
For ships and land units, factoring in build cost overcompensates the
discounted value of construction materials more often than not.
Noteworthy changes for the stock game:
ship type old new change
ss slave ship 20 5.8 * 0.29 largest decrease
cs cargo ship 20 7.8 * 0.39
ts trade ship 60 25.5 * 0.42
frg frigate 12 7.8 * 0.65
bb battleship 24 21.8 * 0.91
cal light carrier 22 30.4 * 1.38
can nuc carrier 30 84.6 * 2.82 largest increase
land unit type old new change
hat hvy artillery 12 9.6 * 0.8 largest decrease
linf light infantry 2.4 3.32 * 1.38
cav cavalry 3 5.4 * 1.8
inf infantry 3 5.4 * 1.8
lar lt armor 3 6.4 * 2.13
com commando 3 15.4 * 5.13
eng engineer 3 30.4 * 10.13
meng mech engineer 3 45.4 * 15.13 largest increase
For planes, the power value change depends on the type. Below a
certain nation tech level, planes of this type become more valuable,
above less.
For the stock game, planes costing at most $1000 become less valuable
at any nation tech level that can build them, and planes costing at
least $1800 become more valuable at any practical tech level,
i.e. under 400. Noteworthy planes:
plane type new
sam Sea Sparrow 2.1 least valuable
f2 P-51 Mustang 4.34
lb TBD-1 Devastator 5.92
jf1 F-4 Phantom 10.6
tr C-56 Lodestar 10.78
jt C-141 Starlifter 15.86
jhb B-52 Strato-Fortress 33.54
ss KH-7 spysat 41.2 most valuable
The old value is a flat 12 at nation tech level 100, 15 at tech level
250, and 18 at tech level 400.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Actual abilities of ships, planes and land units depend almost
completely on the individual unit's tech, not the nation's tech. The
power factor should reflect that.
The power value of a unit is of the form
base value * (20 + nation's tech level) / 500
Change it to
base value * (20 + unit's tech level) / 500
Note that a plane's base value still depends on the nation's tech
level. This commit merely makes the absurdity stand out a bit more.
To be fixed later.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
In the old times, power didn't consider tech at all. Chainsaw's
option NEWPOWER (mandatory since v4.2.14, on by default before)
changed this dramatically: the power factor gets multiplied by
max(1, tech) / 500.
In the early game, small absolute tech differences yield large power
factor differences. For instance, if country A has tech level 10, and
B has 5, then A gets a factor two boost.
As the game progresses, tech differences between viable countries tend
to grow, but only slowly. The influence on power diminishes. For
instance, if C has tech level 270 and D has 240 (quite a respectable
tech lead), then C gets a modest 1.125x boost over D.
Change the factor to (20 + tech) / 500. Now A's advantage is only
1.2, and C's is 1.115.
You might think that's rather low. However, tech is not power unless
you project it, and then it manifests itself as sectors, population
and other stuff power counts.
The same tech term occurs in plane power, except with just tech
instead of max(1, tech) . Change it there as well, for consistency.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Notable gaps in its coverage are fallout, most of guerrilla, delivery,
distribution, ALL_BLEED and LOSE_CONTACT.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
