Moving stuff out of an occupied sector generally requires "military
control", i.e. you need at least one military for every ten civilians.
Military in land units count. Even when the land unit is loaded on a
ship or land unit. Questionable, because unload need not be possible.
Checking whether unload would be possible is not worth the trouble
here, simply ignore embarked land units.
This affects commands move, explore, sell, set and transport, as well
as the update's distribution and delivery.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
update/revolt: Make security bonus proportional to efficiency
Land units with capability security get a combat bonus regardless of
efficiency. This lets players get the benefits of a security unit at
a discount: just don't build it beyond 10%.
Multiply the combat bonus by eff/100. Together with the previous
commit, this closes bug#64.
Note that the the strength of a security unit's commando raid is
already proportional to its efficiency.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
convert shoot: Make security bonus proportional to efficiency
Land units with capability security reduce the mobility cost and have
their military count double, regardless of efficiency. This lets
players get the benefits of a security unit at a discount: just don't
build it beyond 10%.
Count security unit's military times 1 + eff/100 instead of double.
Change the mobility bonus term from number of security units to sum of
security unit efficiency / 100. Partial fix for bug#64.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Infrastructure requires lcms and hcms to build. The build materials
are exposed as infrastructure columns lcms, hcms (struct sctintrins
members in_lcms, in_hcms). They are per point of efficiency. In
contrast, sector and 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 members in_lcms and in_hcms by array in_mat[],
and provide selectors l_build and h_build.
Additionally provide selectors for all other item types, with value
zero, 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>
config: Define infra build cost and mobility use per 100%
Infrastructure build cost is defined by infra column dcost (struct
sctintrins member in_dcost). It's the cost per point of efficiency.
In contrast, sector and unit build cost is defined for 100%, by
sect-chr, ship-chr, plane-chr, land-chr, nuke-chr column cost.
Switch to build cost per 100%, for flexibility and consistency:
replace struct sctintrins member in_dcost by in_cost, and selector
dcost by cost.
With cost values that aren't multiple of 100, the build cost may have
to be rounded. Do this exactly like we round sector build cost: the
amount is limited to money * 100 / cost rounded down, but the money
charged is actual amount * money / 100 rounded randomly.
Do the same for mobility use: replace struct sctintrins member
in_mcost by in_bmobil, and selector mcost by bmobil, with similar
rounding.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
lboard: Don't permit boarding of embarked land units
You can board land units loaded on a ship or land unit. This makes no
sense. Reject attempts to board land units on a ship or land unit
exactly like attempts to board land units that don't exist.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Guerrilla are created loyal to the old owner. When the sector
converts, they switch their allegiance to POGO. This is a bit of a
hack.
When guerrilla win their fight for freedom in an old-owned sector, the
old-owner duly changes to POGO. However, the owner doesn't. Broken
in 4.2.6. The "Sector X,Y has been retaken!" message is still sent to
the "new" sector owner.
Simply restoring the owner change lost back then would restore a bug
that goes back to 2.3.7: takeover() doesn't run when an old-owned
sector is liberated. So fix the bug by making that unconditional.
Land units reported captured are actually destroyed, because POGO
can't own any. Oh well.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
update/revolt: Destroy land units only when casualties demand it
take_casualties() first applies casualties without destroying land
units, and if any remain, applies them by destroying land units. This
is wrong, because the remaining casualties may not suffice to actually
kill. Has been that way since land units were added in Chainsaw 3.
Apply remaining casualties more carefully: destroy land units only
when efficiency falls below 10%.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
update/revolt: Reduce under-strength land unit damage
A land unit with mil military taking N casualties loses N * 100 / mil
points of efficiency. A 50% inf with 20m dies when it loses more than
8m. With 100m, it dies when it loses more than 40m. A land unit
always dies when it loses all military.
In ordinary ground combat, they lose N * 100 / maxmil points of
efficiency, where maxmil is how many military they could load. This
is less damage when the land unit is under-strength. A 50% inf dies
when it loses more than 40m, regardless of how many it has.
An inefficient land unit with a sufficiently high number of military
can die before its military are all killed. A land unit with a
sufficiently low number of military can survive loss of all its
military. Attacking land units return to their starting position.
Defending land units stay put, and get taken over by a victorious
attacker. Neither was possible before 4.0.0 made land unit military
loadable.
The rules for ordinary ground combat may be debatable, but it's better
to be consistent: change land unit damage in guerrilla combat to match
ordinary combat. This reduces damage to under-strength land units.
If che lose, the sector owner profits from the reduced damage. But if
they win, they may take over land units that got all their military
killed.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
update/revolt: Don't kill land units without military
Land units without military can't contribute to the fight. They can
still get killed, and whether they are depends on their UID.
take_casualties() kills land units in UID order until the required
number of casualties is reached. Killing a land unit without military
provides none, but take_casualties() doesn't care. The land unit
"dies fighting guerrillas", which makes no sense when it's doesn't
have any military.
If the rebels win, they attempt to capture any surviving land units.
Spies hide or get executed instead. Same as for any other violent
sector takeover.
Normal ground combat ignores land units without military. Do the same
here: ignore them in take_casualties(). This protects spies and other
land units without military from the fighting, but exposes them to
capture.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
update/revolt: Spread only actual casualties to land units
To spread C casualties among N land units, take_casualties() applies
floor(C/N)+2 to each. Bonkers. Has been that way since land units
were added in Chainsaw 3.
Limit casualties spread to a land unit to their remaining amount.
Should really spread proportionally to military instead of evenly; add
a TODO comment for that.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
take_casualties() applies a number of casualties to sector military
and land units. It is utterly confused about land units.
Consider a land unit with efficiency eff that has mil out of maxmil
military. Issues:
* To apply N casualties without destroying it, take_casualties() tries
to kill N * maxmil / mil military. Makes no sense. It's more than
asked for unless mil equals maxmil. It can even be more than mil.
It reduces efficiency by N * 100 / mil points. Note that ordinary
ground combat reduces by N * 100 / maxmil points. See
lnd_take_casualty().
Example: the update test's inf#25 is 100% efficient and has 20m out
of 100m. take_casualties() tries to apply up to 22 casualties out
of the 60 remaining casualties to apply, but decides to apply only
12 for now, to keep efficiency above to 40%. It reduces efficiency
by 12 * 100 / 20 = 60 to 40%, and tries to kill 12 * 100 / 20 = 60
mil, which kills off the 20 that actually exist. It nevertheless
reduces the number of casualties still to apply only by 12.
Example: the update test's linf#28 is 100% efficient and has 20m out
of 25m. take_casualties() tries to apply up to 8 casualties. It
reduces efficiency by 8 * 100 / 20 = 40 points to 60%, and tries to
kill 8 * 25 / 20 = 10 military.
* When it destroys a land unit, it reduces the number of casualties
still to apply by mil * eff/100.0 instead of mil.
Example: the update test's inf#27 is 10% efficient and has 20m out
of 100m. take_casualties() still has 34 casualties to apply, so it
destroys it, killing all 20m. But it reduces the number of
casualties to apply only by 2.
Broken when 4.0.0 made land unit military loadable. Not sure it fully
worked before that, but it's definitely bonkers since.
Fix it as follows:
* To apply casualties to a land unit without destroying it, limit its
losses to its actual number of military, and so that efficiency
stays above 40%. Then simply kill that number.
* Reduce the number of casualties to apply by the exact number killed.
The update test now kills only 8m in linf#28. Still two more than it
should, but that's separate bug, to be fixed next. The fix has no
visible effect for inf#25, because that one gets destroyed later.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The body count reflects what take_casualties() should do, not what it
actually does. It can be quite off, as the update test's changed
output shows. Mostly because take_casualties() is utterly confused.
That'll be fixed next.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
update/revolt: Fix mil count for che move after getting caught
When military catch che, their their count isn't updated for their
losses. The count is later used when che consider moving to an
adjacent sector. This could conceivably make them move instead of
stay. Broken when Chainsaw 3 added land units. Fix it.
Note that the sector's military count includes land units, but the
adjacent sectors' doesn't. Should be improved some day; add a TODO
comment.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
update/revolt: Change security unit bonus to fix body count
Both ordinary ground combat and guerrilla combat basically kill
combatants one by one randomly until one side is eliminated. The odds
of each side taking a hit are computed from combat strengths.
Ordinary combat factors bonuses into the odds. It doesn't mess with
the number of men.
Guerrilla combat does the same for the bonus due to relative
happiness. It doesn't for land units with security capability: these
fight as if they had twice as many military. Changes both odds and
number of men. This inflates the body count reported to the sector
owner. Visible in tests/update/journal.log, where rebels kill 110 out
of 70 military. It also complicates take_casualties(). Has been that
way since security land units were added in Chainsaw 3.
To fix the body count and simplify take_casualties(), make capability
security affect only the odds, not the number of men. Without further
adjustments, this would reduce guerrilla losses: fewer men mean fewer
combat rounds mean fewer chances for rebels to die. To compensate,
increase the multiplier from two to four. This should make security
units a bit tougher. Document the bonus in "info Guerrilla".
More body count bugs remain.
Reusing ordinary combat rules and code for guerrilla combat would be
nice, but isn't feasible for me right now.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
When an attacking land unit fails its morale check and retreats, the
retreat message needs to be prefixed with a newline to separate it
from the casualty characters. However, the code also prints the
newline when a defending land unit retreats, leaking the retreat to
the attacker. For instance, a fight that forces three defending to
retreat could look like this:
!!!!!!!!!!!!!!!!!!
!@!!!!!!!!!!!!!@!
!
- Casualties -
Yours: 2
Theirs: 34
Messed up in Empire 3. Fix by printing the newline only when an
attacking land unit retreats. The example becomes:
attack assault board: Fix message when attacking land unit dies
Loss of an attacking land is reported like this:
@linf light infantry #1 dies assault 21,-3!
Bad grammar and newline missing between the "@" casualty character and
the message. Messed up in Empire 2. Affects only attackers, because
the code special-cases defense to avoid the bad grammar there (close,
but no cigar), and defenders don't get casualty characters printed.
Fix it to
@
linf light infantry #1 dies assaulting 21,-3!
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The server doesn't let you send land units without offensive strength
into combat: ask_olist() simply doesn't offer them. Good.
However, it needs to offer spies for assault, because assault is how
they sneak ashore. To make it offer spies, which have no offensive
strength, attack_val() artificially sets their offensive strength to
one for assault. Dirt effect: spies fight (and die) in assaults, even
though they can't otherwise attack. Lame. Has been that way since
spies were added in 4.0.0.
Make ask_olist() offer spies regardless of offensive strength when
assaulting, and drop the special case from attack_val(). They get
offered exactly as before. However, since their offensive strength is
now zero, they won't enter actual combat (see the previous commit).
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The server doesn't let you send land units without offensive strength
into combat: ask_olist() doesn't offer them. But if their strength
gets somehow destroyed between ask_olist() and the actual fight, they
go anyway.
Check again before the fight, and leave land units without offensive
strength behind.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
attack assault paradrop: Spies hide rather than defend
Defending spies get spotted like any other defending land unit. They
don't contribute to the defense (their defense value is zero), and
they always survive the fight unscathed (lacking mil, they take no
casualties). If the sector is lost, they either hide or get executed.
Before the previous commit, they could also be damaged and captured.
This lets players use probing attacks to spot spies with a much
better chance than spy or llook have. But they can already repeat
spy or llook to increase their detection chances as close to 100% as
they want, so this doesn't make things materially worse.
* Spy is spotted, attack succeeds, spy gets executed
* Spy is spotted, attack succeeds, spy hides
Since the spy has already been spotted, hiding is largely useless.
The attacker can board the spy as soon as he has mobility.
This obviously hasn't been thought through.
Get rid of the "spy is spotted" cases by skipping spies when
collecting the list of defending land units.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
attack assault paradrop: Execute spies on takeover
When the attacker takes a sector, spies try to hide. If they fail,
they're treated like any other land unit: they attempt to
self-destruct, and if the damage isn't lethal, they get captured.
Successful self-destruct is reported as "blown up by the crew", which
makes no sense for spies. Spies surviving self-destruct is odd, as
any damage is normally fatal for them.
Extend the special case for spies: summarily execute the ones that
fail to hide.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
assault: Improve chance for spies sneaking ashore undetected
Spies assaulting a foreign sector have only a 10% chance to evade
detection, regardless of efficiency. With odds like that, players
basically don't bother.
All the other spy detection checks use LND_SPY_DETECT_CHANCE(eff),
which gives 100% spies a 90% chance to evade detection. That's
perhaps a bit to good here, so let's try LND_SPY_DETECT_CHANCE(eff/2).
A 100% spy now has a 40% chance to sneak ashore undetected.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
assault: Handle the "only spies" special case earlier
Since the previous commit, sneak_ashore() doesn't depend on a previous
get_oland() anymore, so the att_get_offense() is unnecessarily. Move
it across att_get_offense() next to the other special case "assault
own sector".
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
assault: Make spies "sneaking ashore" use mobility and hit mines
Assaulting a foreign sector with nothing but spies is special: the
spies sneak ashore. It is, however, more special than it should be:
the spies use no mobility and ignore landmines. They do use mobility
and hit landmines in other assaults. Assaulting your own sector with
nothing but spies is more costly and more risky than assaulting a
foreign one. This makes no sense. Has been that way since spies were
added in 4.0.0.
It's that way because sneaking ashore uses its own code to move the
spies instead of move_in_land() via att_move_in_off(). It can't use
move_in_land(), because that prints an unwanted "now occupies"
message, and destroys the list of assaulting units, which we still
need to catch and shoot spies.
Factor the code to move attacking land units to the target sector out
of move_in_land() into att_move_land(), and use that for sneaking
ashore. This makes the spies use mobility and hit landmines even when
they sneak.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
ef_verify: Require land unit milit == 0 with capability spy
The rules for spy units make little sense unless spies carry no
military. For instance, spies die when they take casualties in ground
combat. There seems to be a tacit assumption that spies have no
military. I don't trust the code to behave unless this assumption is
met. Require it before an overly adventurous deity finds out the
painful way that spies with military don't work.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
subs: Simplify checks whether a ship just read exists
Ships with efficiency below the minimum have their owner set to zero
on write to the ship file. Therefore, a ship just read from the ship
file exists unless its owner is zero. Additionally checking
efficiency is redundant. Same for planes and land units. Drop
obviously redundant efficiency checks.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
subs: Tighten the check for destroyed defending land unit
get_dland() tests efficiency to find out whether the defending land
unit is gone. Doesn't work when somebody else has since built a new
one with the same UID. Not sure that can happen. Check for a change
of owner instead. Matches get_oland().
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
fire: Plug memory leak when missile defense sinks firing ships
do_defdam() iterates over the list firing ships, applies return fire
to each, and frees its list element. When it finds a ship that has
been sunk already, it skips it. This also skips the free, leaking the
list element. The leak goes back to flawed bug fix in Empire 2.
As far as I can see, missile defense is the only way a ship can be
sunk there.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
subs: Drop unused spy detection roll from unitsatxy()
The die roll was added in 4.0.17 to hide spies from bombers. However,
players could roll dice as often as they wanted, by typing '?' at the
target prompt. The broken die roll is unreachable since commit 7688aed disallowed bombing of spies. Drop it.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
lost: Fix to track more than one lost sector per owner
makelost() overwrites an existing entry for the same thing, else
creates a new one. It calls findlost() to find existing entries.
findlost() means to look up by coordinates if it's looking for a
sector entry, and by ID if it's looking for a ship, plane, land unit
or nuke entry. It actually does both for sectors. Since callers pass
zero ID for sectors, sector entries always match, so at most one gets
created, and additional ones overwrite it.
Broken since the lost table was introduced in 4.0.7. Fix the flawed
comparison in findlost().
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
News reporting merges news items into recent items with same actor,
action and victim, as long as the merged number of times doesn't
exceed 65535 (127 before the previous commit).
This complicates incremental xdump a bit: when the client sees a row,
it's not obvious which of the previously dumped rows it replaces.
Actually, rows with the same actor, action, victim and time replace in
xdump order.
Merge news item regardless of the number of times; saturate the number
at 65535. Now the replacement is obvious, because there can only be
one news item with the same actor, action, victim and time.
This also rate-limits floods of identical news should they happen for
some reason.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
news: Raise the limit for "number of times" from 127 to 65535
News reporting merges news items into recent items with same contents,
until their count reaches 127. Raise that limit to 65535, by making
struct nwsstr member nws_ntm unsigned short. Size of struct nwsstr
stays the same on all common machines.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
This is one of the lamest ways to sort I've seen in my career: find
the maximum, then for each value from the maximum down, search for
that value. O(max * MAXNOC^2). Dates back to Empire 2.
The one advantage this contraption has is it "sorts" in place. But
memory's cheap. Fill an array with the data to sort, and sort it with
qsort(). To avoid overtaxing the stack in the (unlikely!) worst case
of everybody taking sectors from everybody, allocate it dynamically.
Also flip sectors_taken[] from short to unsigned short. Aside: in
theory, the count can overflow, but sector deltas exceeding 65535
don't occur in practice, and if news misreported them, we'd live. Not
worth complicating the code.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Version information is in output of commands version, xdump version,
and in program output for option -v. Looks like this:
Wolfpack Empire 4.3.33
The version number is defined in configure.ac, and incremented
manually. It identifies only the base release (here: 4.3.33). Fine
when this is an unmodified released version. Pretty much useless
during development.
Add a suffix to the version number that describes it further:
V Unmodified release V (same as before)
V.N-H Modified release built from a clean git tree
N is the number of additional commits, and
H is the abbreviated commit hash
V.N-H-dirty Same, but the working tree is dirty
V-dirty Modified release built from a tarball
A git tree is clean when the contents of its files are unchanged.
Changing only the their timestamps doesn't count. It does count when
building from a tarball, because tracking contents isn't implemented
there.
Also use this suffixed version for tarball names.
The version reported by configure is fixed at configure generation
time, i.e. it is usually out of date during development. Ensuring a
release tarball contains one with a current version is manual for now.
Running autoconf -f should do the trick.
Elsewhere, the version is determined at build time, so it is always
current.
Dirty tracking isn't implemented in the standalone client build. If
you start with a clean tarball, the version will not change from V to
V-dirty when you build with modifications.
Steal build-aux/git-version-gen from autoconf 2.69 to help with
computing the version string.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
nsc filetable: Get rid of untidy use of PACKAGE_STRING
Table version selector version shows the version string stored in
version[]. Its implementation is a bit of a hack:
empfile[EF_VERSION].cache is set to version[], so it gets passed as
context object to nstr_eval(). This permits reading version[] with an
NSC_STRINGY selector at offset 0, which is what nsc_init()'s
version_ca0 is.
Both empfile[] and version_ca need the size of version[]. Since
version.h provides only an incomplete type for version[], they use
sizeof(PACKAGE_STRING), which isn't exactly clean.
Redo version_ca0 as virtual selector. Takes a bit more code, but it's
easier to understand.
The context object is now unused. Setting empfile[EF_VERSION].cache
to a null pointer would trip assertions, so make it point to a dummy.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
xdump: Make meta-type numbers portable, get rid of meta-type "c"
The xdump field data types are abstract symbols "d", "f", "s" and "c".
However, the abstraction leaks: we dump the enum nsc_type ca_type
values verbatim in meta table field "type", and have symbol table
meta-type map all integer types to "d", and both floating-point types
to "f". Not a problem for well-behaved clients, since all they do
with the dumped value is referencing table meta-type. It is a problem
for version-test: since the integer type compatible with an
enumeration type is implementation-defined, the type value of
selectors of enumeration type can vary between compilers. It also
makes table meta-type a somewhat ugly exception to the rule that a
symbol table maps integers to names 1:1.
Virtual selectors let us seal the abstraction: dump the promoted
ca_type value.
The integer types get all promoted to NSC_LONG. This takes care of
version-test.
The floating-point types get all promoted to NSC_DOUBLE. Makes sense.
NSC_STRINGY gets promoted to NSC_STRING. This changes all field data
types "c" to "s". Getting rid of "c" is a welcome simplification,
because now the meaning of meta type field "len" no longer depends on
"type", but always means that the array is dumped as that many fields.
We lose string length limit information, though.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
ef_verify: Run verify_row() even for tables without selectors
verify_table() skips verify_row() when the table doesn't have
selectors. But verify_row()'s test for corrupt headers in EFF_TYPED
tables doesn't require selectors. Harmless, since the two tables that
don't have selectors (EF_MAP and EF_BMAP) aren't EFF_TYPED. Clean it
up anyway.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Virtual selectors can't be used in xundump, since we lack a setter to
go with ca_get(). verify_ca() verifies they don't occur in tables
that can be xundumped.
When I restricted xundump to tables with a file name (commit 029d929,
v4.3.28), I neglected to update the test in verify_ca().
Factor out the correct test into xundumpable(). Use it to fix
verify_ca().
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
update: Delivery abandons sectors incorrectly, fix it not to
Deliver fails to abandon sectors when it ships out all civilians and
military. The sector remains owned until the next non-update sector
update abandons it. Has always been broken.
Distribution had the same bug until commit d0f3847 (v4.3.20) fixed it.
Fix it the same way for delivery: adjust the amount moved to avoid
moving out the last civilian, or the last military if there are no
civilians.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
update: Reorder feeding, tax & plague for consistency
People in sectors get plagued, then taxed or paid, then fed. People
on ships and land units get paid, then fed, then plagued. Sectors
were messed up when Empire 3 made the update code work for budget.
Change sectors back to how they worked before Empire 3: move do_feed()
from produce_sect() to prepare_sects(), and delay do_plague() until
after do_feed(). People in sectors now get taxed, paid and fed even
when they die of the plague, just like they do on ships and land
units.
Because do_plague() now runs after populace(), the latter's handling
of people dying off doesn't cover plague anymore. Delay it to the
very end of prepare_sects().
Additionally, move feeding and plaguing from upd_ship(), upd_land() to
prep_ship(), prep_land(), for consistency with sectors.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
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>
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>
update: Reorder unit building and maintenance for fairness
The update visits ships, planes and land units in increasing order of
country number. Within a country, it visits first ships, then planes,
then land units, each in increasing order of unit number.
The order is relevant when money, materials and work don't suffice to
build everything.
Money is charged to the owner, so only the relative order for the same
owner matters there. One order is as good as any.
Work and materials come from the sector, so only the relative order in
each sector matters. The current order unfairly prefers countries
with lower country numbers. Mitigating factor: the affected countries
need to be friendly (ships only) or allied.
The unfairness goes back to Chainsaw's option BUDGET. See the commit
before previous for more detailed historical notes.
The update test demonstrates the unfair behavior: sector 14,6 builds
ships 95/97 owned by country#1, but not 96 owned by country#7.
Likewise, planes 95/96/97 and land units 95/96/97.
Go back to the the pre-BUDGET order: first ships, then planes, then
land units, all in increasing order of unit number, regardless of
owner.
The update test now builds ship, plane and land unit 96 instead of 97.
Bonus: speeds up both the update and budget by a similar absolute
amount. For budget, this is roughly a factor of two in my testing.
For the update, which does much more, it's around 10%.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
budget: Fix for ship, plane, land unit building abroad
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>
update: Fix ship, plane, land unit repair work use abroad
Ship, plane and land unit repair uses new work, except in sectors
owned by countries with a higher country number.
This inconsistency is an artifact of how the update is sequenced: we
work on countries one after the other. A country's ships, planes and
land units get repaired before higher-numbered countries' sectors
produce. Any ship, plane and land unit repairs in such sectors use
old work instead of new work.
Repair work use changed several times during Empire's history.
In BSD Empire, repairs use old work, because it updates ships and
planes before sectors.
Chainsaw added budget priorities and the budget command as option
BUDGET. Budget priorities let players choose separately for ships,
planes and land units whether to use old or new work for repairs.
The option also changed the update to work on countries one after the
other, presumably to permit a more efficient implementation of the
budget command.
Chainsaw also introduced repairs in foreign sectors under option
ALLYHARBORWORK.
With BUDGET disabled, all repairs still use old work, whether at home
or abroad. With BUDGET enabled, work use of repairs at home depends
on budget priorities, but work use abroad depend on country numbers.
Both options became standard in Empire 2.
Since v4.3.6, repairs at home always use new work (commit 967299a and
commit 520446e).
To make repairs abroad always use new work as well, we need to update
all sectors before any ship repair. This is straightforward: split
the loop over countries between sectors and unit building. For
symmetry, also split it between unit maintenance and sectors.
The budget command is differently broken, and will be fixed next.
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>
update server: Move update_running from server/ to update/
update.h is a more logical home for update_running than server.h.
Move the definition and the assignments along, from server/update.c to
lib/update/main.c.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The do_upd_checking recursion guard is superfluous: do_mob_sect()
doesn't call anything. Has been that way since MOB_ACCESS was added
in Empire 3.
Inline the remaining code of sct_do_upd_mob(), shp_do_upd_mob(),
pln_do_upd_mob(), lnd_do_upd_mob() in their only callers
sct_postread(), shp_postread(), pln_postread(), lnd_postread().
Rename do_mob_sect(), do_mob_ship(), do_mob_plane(), do_mob_land() to
mob_sect, mob_ship(), mob_plane(), mob_land() and give them external
linkage.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
update: Separate MOB_ACCESS from normal mobility update
The update uses mob_sect(), mob_ship(), mob_plane() and mob_land() for
two related, but different jobs: to give the previous turn's remaining
MOB_ACCESS mobility, and to give this update's new mobility. The two
were probably conflated in an attempt to share code, but it actually
just complicates things.
Collect the MOB_ACCESS code in new function mob_access_all(), and the
normal mobility update code in new function mob_inc_all().
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
update budget produce: Count loaded civilians for TECH_POP
When option TECH_POP is enabled, the cost of tech increases when
civilian population exceeds 50000. Only civilians in old-owned
sectors count. This differs from education and happiness, where
civilians loaded on ships and land units count, too.
The update counts population for TECH_POP with count_pop(). This is
an extra pass over all sectors.
produce also uses count_pop(), once per tech center examined.
Wasteful.
budget avoids count_pop(): it uses tax()'s civilian count. More
efficient, but the difference to the update is ugly.
Change TECH_POP to use the same civilian count as education and
happiness, i.e. count civilians on ships and land units, too.
This count is available in nat_budget[] in time for produce(): it's
computed by tax() and by ship and land unit maintenance. So use it
there. This takes care of the update and budget. produce doesn't run
enough update code to do the same. Keep calling count_pop() there.
Update it to match the update, and give it internal linkage.
Duplicating update's workings there is ugly, so mark it FIXME.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
update budget: Fix civ counting for happiness and education
Per-civilian happiness and education production is raw production
divided by the number of old-owned civilians. The update reports the
number of old-owned civilians ("total pop was %d").
This number of civilians is also used by budget to predict cost of
tech when option TECH_POP is enabled, but that doesn't match how the
update computes the cost. To be fixed next.
Civilians loaded on ships are only counted by the update, not by
budget. Harmless, as budget doesn't compute happiness and education.
Civilians loaded on land units are ignored by both. None of the stock
game's land units can load civilians.
Civilians in sectors are counted before plague deaths, and in ships
afterwards.
Fix upd_ship() and upd_land() to count civilians the same way as
prepare_sects() does for sectors.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
production: Use update code instead of duplicating it
prod() duplicates the update's sector production code, except it
computes both output with present materials ("make" output) and output
not limited by lack of materials or production backlog ("max" output).
It also rounds materials consumed up instead of randomly.
Factor prod_output() out of produce() for reuse by prod(). prod()
runs it twice: once for "make" output and once for "max" output.
Test output changes are due to random rounding.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
update production: Make sector production a bit more predictable
Sector production computes a number of intermediate values, and rounds
many of them. We've tinkered with the rounding a few times. It
currently works as follows.
There are two production efficiencies, both shown by the production
command: sector p.e. (column eff) governs how efficiently work is
converted to units of production, and p.e. (column p.e.) governs how
much product each unit of production yields.
Production is limited by available work, materials and resource
contents. These limits are all rounded down.
Example: if a unit takes 16 work (tech or guns), then 600 work at 100%
sector p.e. can make at most 37 units, rounded down from 600 * 100% /
16 = 37.5. 76 work at 76% sector p.e. can make 3, rounded down from
76 * 76% / 16 = 3.61.
Output is units times p.e. Level output isn't rounded. Item output
is rounded down.
Example: a tech center making 37 units at p.e. 0.6 (edu=20) yields 37
* 0.6 = 22.2 tech (before tech log). 3 units yield 1.8 tech.
Example: a defense plant making 37 units at p.e. 0.6 (tech 35) yields
22 guns (rounded down from 22.2). 3 units yield 1.8g, randomly
rounded.
If item output needs to be adjusted downward (production backlog), the
number of units made is likewise adjusted. It is rounded randomly.
Example: a 100% refinery with 156 work can make 156 units. Its
p.e. at tech 30 is 5.0, so this yields 780p. But if it already has
9500p, it can make only 499 more. That's 99.8 units, rounded randomly
to either 99 or 100.
Materials and money consumed are a multiple of units made. No
rounding there.
Resource depletion depends on units made and is rounded randomly.
Work consumed is units made times work per unit divided by sector
production efficiency. Rounded randomly. Any work left can normally
be used at the next update (it "rolls over").
Example: the tech center making 37 units consumes 37 * 16 / 100% = 592
work, with 8 work left. It also consumes 37d 185o 370l $11100.
Example: the tech center making 3 units consumes 3 * 16 / 76% = 63.2
work, randomly rounded to 63 or 64, with 13 or 12 work left. It also
consumes 3d 15o 30l $900.
Example: the defense plant making 3 units consumes work the same. It
additionally consumes 1o 15l 30h $30 when it makes one gun, and twice
as much when it makes two.
Rounding intermediate values like "units of production" is awkward.
It's better to round only final results. These are item output,
materials consumed, resource depletion and work consumed. Round item
output down, and the rest randomly. Don't round level output (it's a
floating-point value) and money consumed (also floating-point, since
the previous commit).
For item production, this shifts the random variations from number of
products made to materials and work consumed.
Example: the first defense plant again makes 22 guns (now rounded down
from 22.5). The second one now always makes two guns (rounded down
from 3.61 * 0.6 = 2.166) instead of 1.8 randomly rounded.
This is nice, because budget and production can now predict the number
of items made exactly. Before, budget fluctuated randomly just like
the update, and production rounded down.
Note that budget used to be even worse: until commit 6f7c93c
(v4.3.31), we rounded units of production randomly rather than down.
The 100% tech center randomly made 37 or 38 units, which is much more
relevant than random rounding of item output.
Furthermore, work is now fully used both for item and level
production, to the limit permitted by materials and resource contents.
Example: the first tech center now makes 37.5 units, yielding 37.5 *
0.6 = 22.5 tech. It consumes 37.5d 187.5o 375l $11250 and all 600
work (fractions randomly rounded).
Example: the second tech center now makes 3.61 units yielding 1.805
tech, consuming 3.61d 18.05o 36.1l $1083 and all 76 work.
The production command duplicates much of the update's sector
production code, so it needs a matching update. The next commit will
reduce the duplication.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
update: Don't double-round money, fixing mil pay and more
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>
update: Push budget update into produce(), enlist()
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>
projects / empserver / log