Fix the bug demonstrated by the previous commit:
take_casualties_from_lands() limits total casualties to @each. It
should limit each land unit's casualties, and only if !may_kill. This
can lead to fewer casualties than called for; oops in
take_casualties(). Broken in commit 025e9cc25, v4.4.0.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The next commit will create a contact file, and the macro to get a
contact entry will be named getcontact(). Rename the existing
getcontact() out of the way.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
When option LOSE_CONTACT is enabled, contact is lost after a few
updates. The remaining number of updates is to be decremented by one
each update. However, it's actually decremented every time an active
nation is updated. This makes countries lose contact much too fast,
typically every update. Broken in commit ac25058, v4.3.0.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
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>
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>
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>
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>
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>
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>
Since the previous commit fixed the update of mc, mc + taken remain
invariant. Don't bother changing mc, use mc - taken instead.
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>
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>
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>
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>
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>
Several headers define macros that use ef_ptr() without including
"file.h". Fix that. Drop redundant inclusions elsewhere.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The update visits sectors in increasing order of country number.
Within a country, it visits in increasing order of sector number,
which is effectively top to bottom, left to right, starting with
absolute 0,0.
The order doesn't actually matter. Before Chainsaw's option BUDGET,
the update simply visited the sectors in sector number order. Go back
to that order, because it's faster. For the update, it's a few
percent in my testing. For budget, it's more than a third.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The 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>
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>
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>
People in sectors first eat, then build the sector, then produce.
People in ships produce, eat, then build.
The starvation command can be off for fishing vessels, because it
doesn't consider the food they produce.
Change ships to match sectors. "Fixes" starvation. Fishing boats and
oil derricks being repaired at sea become a bit more productive.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
No maintenance is paid when the sector is stopped or the owner is
broke. Broken in commit 44c36fa, v4.3.23. Fix it.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
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>
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>
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>
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>
