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>
Tweak military in land units to demonstrate that
take_casualties_from_lands() can kill fewer military than it should.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Commit 35ecc008c fixed take_casualties() to destroy land units only
when casualties demand it. This test demonstrated the change: inf#29
no longer dies. Good. However, this lost coverage of land units
dying in a sucessful defense. Bad.
I could tweak inf#29 to get destroyed again, but that would lose
coverage of the bug fixed by commit 35ecc008c. Make linf#28 die
instead.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Relations state is relatively bulky: it's a big chunk of struct
natstr, and adds 200 bytes per country to xdump nat.
Relations change rarely. Rewriting it to disk on every nation update
and retransmitting it in every xdump nat is wasteful.
To avoid this waste, move relations state to its own struct relatstr.
This is of course an xdump compatibility break. We're not maintaining
xdump compatibility in this release.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
New struct relatstr is basically empty so far. The next commit will
move relations state from struct natstr to struct relatstr.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Reject state is relatively bulky: it's a big chunk of struct natstr,
and adds almost 200 bytes per country to xdump nat.
Reject state changes rarely. Rewriting it to disk on every nation
update and retransmitting it in every xdump nat is wasteful.
To avoid this waste, move reject state to its own struct rejectstr.
This is of course an xdump compatibility break. We're not maintaining
xdump compatibility in this release.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
New struct rejectstr is basically empty so far. The next commit will
move reject state from struct natstr to struct rejectstr.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Contact state is relatively bulky: it's a big chunk of struct natstr,
and adds almost 200 bytes per country to xdump nat for deities.
Contact changes rarely. Since we avoid unnecessary updates, it
doesn't change at all unless option HIDDEN is enabled. Rewriting it
to disk on every nation update and retransmitting it in every deity
xdump nat is wasteful.
To avoid this waste, move contact state to its own struct contactstr.
This is of course an xdump compatibility break. We're not maintaining
xdump compatibility in this release.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
New struct contactstr is basically empty so far. The next commit will
move contact state from struct natstr to struct contactstr.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
A country must always be in contact of itself when option HIDDEN is
enabled. The code ensures this by establishing contact whenever a
player logs in, in init_nats(). This is not the proper place. Game
state should be initialized in empfile's oninit() callback, in this
case nat_oninit(). Do that, and drop the putcontact() from
init_nats().
Note that option LOSE_CONTACT only affects contact to other countries:
agecontact() doesn't age the country's contact to itself.
Use the opportunity to initialize contact so that getcontact() works
even when HIDDEN is disabled. Just cleanup, it isn't actually called
then.
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Extend struct budget member bm[] to cover ships, planes and land
units, too.
Plane maintenance changes because pilot pay is now consistently
rounded down. Before it was rounded down for broke countries, else
up. The stock game's pilots earn a little less than $25, and solvent
countries save $1 per plane. The rounding doesn't make much sense
either way. To be be addressed in a later commit.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
When we add up military payroll, we discard fractions. Payroll is
therefore lower than it should be, but I'm not fixing that now. The
number of military budget reports is actually computed from payroll,
and therefore also low.
The obvious way to fix that would be adding another out parameter to
tax() and upd_slmilcosts(). However, budget and the update track cost
and count of numerous things (sector products, unit maintenance and
building, ...), and it's time for a common way to do that.
Create struct budget_item for tracking cost and count, and struct
budget nat_budget[MAXNOC] for tracking a nation's budget. Track only
military for now; more to follow.
This fixes the military count. The cost of military remains low,
because we discard fractions exactly as before.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
People don't work when their sector is stopped or their nation is
broke. Implemented by produce_sect() skipping the assignment of new
work returned by do_feed() to sct_avail.
This is wrong because it lets all old work roll over, ignoring
rollover_avail_max.
Broken in 4.0.0. Similarly broken for sectors disabled via zero
budget priority between a botched fix for changing sector types in
Chainsaw and the removal of budget priorities in commit 520446e,
v4.3.6.
Fix by zapping available work when the sector is stopped or its owner
is broke.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Traditionally, unused unused available work is discarded at the
update. Since commit d7a054c (v4.2.13), deities can configure (some)
unused work to "roll over", i.e. available work = some unused work +
this update's work.
Not discarding unused work reduces micromanagement incentives.
However, it also leads to unobvious behavior.
For instance, here's the obvious way to build a radar station: move in
enough people to make 200 work. Half of it is available for sector
building, and increases efficiency to 100%. Here's a not-so-obvious
way: move in enough people to make 134 work. 67 will be used to
increase efficiency to 67%. Now move your workers elsewhere. The
unused available work is enough to finish the job at the next update.
Similarly, neighbors could be surprised by sectors building bridges
despite having no visible workers.
Commit 7f4e59f (v4.2.15) let deities limit the amount rolled over:
unused work above rollover_avail_max is discarded. This became the
default with a value of 50 in commit 81a3e4c4, v4.3.31.
Limit it further so that "roll over" can increase the update's work by
no more than half, plus one. The extra point is there so that even a
tiny work force has a chance to eventually eke out the second point of
work needed to increase efficiency.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Rounding work down can lead to a bit of work micromanagement. For
instance, four military on a lonely island accomplish nothing in 60
ETU updates, but five will make one point of work per update. They
can build a 2% harbor in four updates, as long as rollover_avail_max
is at least 3. Six to eight will be no faster.
The people's work used to be rounded randomly until Empire 3's big
effort to make the update code work for budget switched to rounding it
down, perhaps accidentally.
Switch back to rounding randomly, so that players don't have to get it
exactly right. Four military now get to 2% in five updates on
average, five in four, six or seven in three, and so forth.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
buildeff() rounds work and money up. Until recently, fractions could
only occur on tear-down, but with customized costs they can now also
occur on build-up.
The previous commit changed unit building to round money and work
randomly. Before, money was rounded down, and work was rounded up.
Round them randomly for sectors as well, for consistency.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
shiprepair() limits the efficiency gain to how much the workers can
build, rounding randomly. It charges work, money and materials for
the efficiency actually gained, rounding work up, money down, and
materials randomly. Same for planerepair() and landrepair(). Has
always been that way.
If you get lucky with the random rounding, you may get a bit of extra
work done for free.
The budget command runs the update code, and can be off by one due to
different random rounding.
Sector production used to have the same issue, only more serious,
because a single unit of tech production matters much more for the
budget than a single point of unit efficiency gain. I fixed it in
commit 6f7c93c, v4.3.31.
Fix it for unit building the same way: limit efficiency gain to the
amount the workers can produce (no rounding). Work becomes a hard
limit, not subject to random fluctuations. Randomly round work and
money charged for actual gain, like we do for materials. On average,
this charges exactly the work and money that's used.
This lets budget predict how much gets built a bit more accurately.
It's still not exact, as the amount of work available for building
remains slightly random, and the build cost is randomly rounded.
The old rounding of work for ships carries the comment "I didn't use
roundavg here, because I want to penalize the player with a large
number of ships." Likewise for planes. Rounding work up rather than
randomly increases the work cost by 0.5 per ship, plane or land unit
on average. I could keep the penalty by adding 0.5 before random
rounding. Not worth it, since the effect is actually pretty trivial.
Let's examine a fairly extreme case: an airfield with 600 available
work repairing a huge number of lightly damaged planes, say f2 with
81% average efficiency. The old code lets the airfield repair roughly
600 / 6.5 = ~92 planes, the new code 600 / 6 = 100.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Replace the term
power value of materials and cost + 9
by
power value of materials and cost + maximum population / 1000 * 8 + 1
The value of ordinary sectors (maximum population 1000) doesn't
change. The stock game's mountains, plains and bridges are now worth
only 28% as much.
This concludes my tweaking of the power factor for now. I tested it
with data from a real game (Hvy Metal II). The effect is small: #5
overtakes #4, and the lead of #1 over #2 and #3 shrinks some. Closer
analysis finds the following reasons. The game had very expensive big
cities. Valuing them correctly gives countries with many cities a
noticeable boost. Planes are worth less than before, but the
difference is much larger for cheap planes. Big piles of construction
materials are worth much less, and shells, guns and bars are worth
more.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Building sectors can make you rate *lower* on the power chart, because
the power factor treats all sectors the same, regardless of build
materials and cost.
To avoid that, replace the term
efficiency / 10.0
by
(power value of materials + power value of cost + 9)
* efficiency/100.0
The value of ordinary sectors, which take no materials and cost $100,
doesn't change. The stock game's fortress is now worth 80% more due
to its materials and higher cost. The stock game's wilderness is
worth 10% less, because it costs nothing.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Update code shared with budget uses the bp map instead of the sector,
so that budget can track materials and work available in sectors for
ship, plane and land unit building without updating the sector file.
Unfortunately, the bp map can become stale during the update.
prepare_sects() doesn't update the bp map for sea sectors, unlike
budget's calc_all(). Instead, we rely on calloc()'s initialization.
Works, but is a bit unclean.
prepare_sects() updates the bp map after fallout, but neglects to
update it for any of the later sector updates (steps 1b to 1f in info
Update-sequence). Che can destroy materials and available work, and
the plague can kill military. The bp map stays out of date until
produce_sect() updates it again.
Since we deal with sector production and countries in increasing order
of country number, foreign ships, planes and land units owned by
countries with lesser numbers get built before their sector produces.
Building uses the stale bp map then, and can use materials and
available work destroyed by che or the plague. The update test
demonstrates the former case.
For stopped sectors or when the owner is broke, produce_sect() updates
only materials in the bp map, not available work. Nothing builds in a
stopped sector, but allies may build in your sectors even when you're
broke. They can use available work destroyed by che then.
Screwed up when Empire 3 made the update code work for budget.
Note that budget bypasses the flawed code: it prepares its bp map
itself instead of calling prepare_sects().
Rather than fixing prepare_sects(), use a null bp map for the update:
writes become no-ops, and reads read from the underlying sector. Not
only does this remove the possibility of the bp map going stale during
the update, it saves a bit of memory, too.
calloc()'s initialization is now dead. Switch to malloc().
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
