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.
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.
Replace the fixed $1 per ETU maintenance for capital/city sectors that
are at least 60% efficient by a configurable maintenance cost, payable
regardless of efficiency. The only change in the default
configuration is that inefficient capitals now pay maintenance.
Charging sector maintenance regardless of efficiency is consistent
with unit maintenance.
New struct dchrstr member d_maint and sector-chr selector maint. Make
show_sect_build() show it. Change produce_sect() to record
maintenance in new slot p_sect[SCT_MAINT] instead of abusing
p_sect[SCT_CAPIT]. Replace the "Capital maintenance" line in budget
by "Sector maintenance".
Food supply during update adds complexity to the update. How much
good it does to players is highly doubtful; certainly nobody can rely
on it. It isn't covered by the starvation command. Starving ships or
land units can steal enough food from their sector to make it starve,
too. Finally, the supply code is notoriously hard to use correctly.
We don't know of issues with the update's use, but we haven't
convinced ourselves that there aren't any either.
negative. Some places considered $0 as bankrupt, some didn't. Fix
the ones that did:
(repo_list): report command misreported countries with $0 as broke.
(init_nats): If you had $0, logging out and back in bankrupted you.
(produce_sect, upd_ship): Failed to build sectors and produce stuff
for countries with $0.
This is more robust than using bp_put_item() for those elements of
vec[] that the call may change. The old code missed some changes:
upd_buildeff() changing population when tearing down a big city,
enlist(), and produce(). The first two should have been harmless, the
last one made budget mispredict repairs when required materials were
produced in the same update.
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.
so that stopped sectors don't repair units. The update sequence
masked this bug until its change in src/lib/update/main.c rev. 1.25,
but use of budget priorities (gone since rev. 1.24) could unmask it.
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.
(P_LCM, P_HCM, P_TLEV, P_RLEV, P_ELEV, P_HLEV, P_URAN): Use -1 instead
of 0 for `no product', shift down product indexes and update
product.config and sector.config accordingly.
(budg, prod, show_sect_capab, produce, produce_sect): Adapt test for
no product.
(ef_elt_byname): Remove the hack to hide pchr[0].
(prod_eff): Oops on no product.
regardless of the option, but forced to sct_effic when disabled. This
screws up sct_defense when you disable DEFENSE_INFRA. Implement it
more like FALLOUT: use sct_defense if enabled, else sct_effic. The
change should be invisible except in xdump, which shows the real
sct_defense. Closes#804641.
(SCT_DEFENSE): New.
(dump, sinfra, sector_strength): Use it.
(eff_bomb, build_bridge, build_tower, new, buildeff, sect_damage)
(put_combat, checksect, produce_sect): Don't force sct_defense to
sct_effic when DEFENSE_INFRA is disabled.
